Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Tiktaalik

Pages: [1] 2 3
1
NGUI 3 Support / Perform Anchor calculations immediately before Start()?
« on: October 21, 2014, 04:40:55 PM »
I have a situation where I want to have UILabel (WidgetA) with a child anchored to it (WidgetB) that will wrap around the UILabel. When I set a bunch of text to the UILabel, the label will expand for the text and I want to immediately have the child WidgetB update its anchors and expand to contain WidgetA. I want this to occur immediately so that I can immediately query the new size of WidgetB. How do I force these calculations Immediately?

As it stands to get this to work I can call

  1. WidgetA.text = value;
  2. //We must use "localSize" here as UILabels recalculate their text processing on when localSize is called.
  3. //Calling localSize will force this recalculation immediately.
  4. var size = WidgetA.localSize;
  5. WidgetB.UpdateAnchors();
  6. var sizeB = WidgetB.localSize; //<-- not going to be correct.
  7. ....
  8.  

However at this point sizeB will not be correct. Later on in the Start() I'll be able to fetch the size of WidgetB and it'll be correct.

So my core issue is that I'm not really clear on how Anchors work at the low level. Is there's some aspect of their functionality that requires on the objects being active or enabled and UpdateAnchors() doesn't get around this? Is there a way to force the calculations immediately even if I'm calling on objects prior to their Start()?


2
Of course you're right. We have source control so we could easily roll back.

3
Ok that worked thanks.

I'd love to upgrade NGUI, but we're in the thick of things at the moment and I'm really not able to risk having some sort of compatibility problem.

It's a shame that Unity doesn't have a better upgrade system that would allow you to roll back in case something goes wrong.

4
I'm trying to build an inset widget (let's call it InsetWidget) much like what is described on the UIRect documentation, but designed such that the inner widget is a UILabel that resizes its height based on the text. As the inset UILabel expands, the outer containing UIWidget should also expand.

I've been able to create this by having the UILabel not anchor its bottom, and having the containing UIWidget anchor its bottom to the bottom of the inset UILabel.

Unfortunately I'm getting very weird bugs where this InsetWidget's height is drifting slowly larger. I've also on re-running seen an issue where the height of the UILabel was going back and forth between a negative and positive value, causing the whole thing to wobble.

Is this a legitimate way to build this sort of Widget or will doing this always lead to problems?

(As well these widgets are being added to a UITable if that means anything. I haven't yet tested how this runs outside of that situation)

Running NGUI 3.5.5

5
NGUI 3 Support / Re: About moving ui object
« on: October 06, 2014, 07:52:30 PM »
I'm actually having this issue as well... Very odd. In one of my projects I have handles off and I get the transform gizmo, but in the other I can't get the transform gizmo no matter what.

Running 4.5.4f1 and NGUI 3.5.5

Any ideas of what could be causing this? The fact that it works fine in one project but not the other seems like a hint, but I don't know what to try next.

After some comparing with my working project I've found an issue.

Disabling gizmos on UIPanel brings back the transform gizmo.

6
NGUI 3 Support / Re: About moving ui object
« on: October 06, 2014, 04:09:54 PM »
Was able to verify that this handle option work-around works fine in another project. Not sure what strange combination of things is making the standard Unity gizmo not show up after disabling handles in the Undead Overlord project, but apparently I *am* the only one having that problem. :-)

Still, multi-drag for multiple selected widgets without having to dig into the options would be a nice addition.

Thanks, as always, Michael, for the ongoing NGUI improvements . . .

I'm actually having this issue as well... Very odd. In one of my projects I have handles off and I get the transform gizmo, but in the other I can't get the transform gizmo no matter what.

Running 4.5.4f1 and NGUI 3.5.5

Any ideas of what could be causing this? The fact that it works fine in one project but not the other seems like a hint, but I don't know what to try next.

7
NGUI 3 Support / Sometimes widgets don't render after legacy animation.
« on: August 21, 2014, 01:12:39 PM »
Preamble: I have a fix for this problem but I wanted to make a post about it to find out more about how NGUI works and to provide a solution in case anyone else ever comes across this same issue.

I found a weird problem when running our game on old slow iPhones (3GS and 4). In situations where we activate an UIPanel and then perform a legacy animation on it, we arrive at a situation where the widgets on the panel aren't visible, but when you click on the space where they should be, they blink into existence. It is like they are actually there, but they have not been drawn. If you zoom out however, you can see that the widgets are actually remaining in their original, pre-animation positions. Very odd. Since we didn't see the animation play, we suspect what is happening is that the activation of the Panel and all its widgets is taking so long that the animation is actually completed before the widgets were active. Somehow after this the widgets are in some weird state that I don't fully understand.

I thought I'd be able to fix this by forcing a UIPanel.Refresh(), but that didn't work. I was able to fix it however with this following code:

 
  1. foreach(var w in m_uiPanel.widgets){
  2.     w.MarkAsChanged();
  3. }
  4.  
  5. m_uiPanel.Refresh();
  6.  

In this thread you mentioned that

Quote
Panel's Refresh() will refresh the draw calls, but only of the widgets that have been registered with the panel. MarkAsChanged registers the widget with the panel.

Are the widgets being unregistered somehow? Or is it that some other code that is supposed to mark widgets as changed never runs in this case? I'm not really sure why I have to manually mark all the widgets as changed.


8
I'm currently tracking down a pause in our game that I believe is due to Font.CacheFontForText. To solve this problem I need to get a better feel for how our use of fonts in screens at that moment is affecting the game's performance.

I want to test whether disabling certain NGUI UILabel options (ie. shrink text, shadow) will have enough of an impact to solve the issue or whether it's irrelevant.

Is there a way in Unity to see a snapshot at runtime of what memory Unity has allocated for Fonts in particular? What would be the best way to approach debugging this problem?

9
Ok I understand now. The UITable is independent of UIScrollView.

I became confused I think because UIScrollView's ContentOrigin option was being assigned to TopLeft and it seemed odd to me to not see my content not appear in the top left of the UIScrollView.

To make my tables make the most visual sense I'll manually set the UITable position to be the top left of the UIScrollView (-150,150) then set the child UIWidgets to be pivoting on the top left and set their transforms to 0,0.

10
Do you have the "Content Origin" of your ScrollView set to "TopLeft"? Do so, and then right-click on the UIScrollView component and choose ResetClippingPosition. This should re-position your table to the top-left of the scroll view, or any other origin you choose.

To do this in code, call UIScrollView.ResetPosition();

Does that help with your issue?

I've played around with Content Origin, and while I can see how it's modifying the position of the content, the table still seems to start positioning its child objects at its origin.



What happens here is that when I select ResetClippingPosition the clipping offset get set to 0, -99 from 0,0 and transform is set to 0, 99, 0 from 0, 0, 0.

11
Just putting my two cents into this discussion, the UITable script appears to start positioning it's elements always beginning from it's own position, leading downwards and to the right.

So if you move your UITable GameObject to the upper-left bound of your Scrollview, you might get what you want.

Yeah that's the fix that we've been using to have our tables appear correctly, but I wanted to bring this up because it's pretty confusing and I wasn't sure if this was the intended behaviour for the UITable or a bug.

12
Got it, thanks. Your issue is simply in the fact that you never actually executed the table you have. It doesn't execute until after you hit Play unless you right-click the component and choose Execute.

So nothing was actually aligned at all.

If you select Execute you get the following result:



Cells are still off to the side.

To me it looks like the table cell is being positioned such that its top left point is positioned to the Center point of UIScrollView. Is that how this feature is supposed to work? It looks like either there is a bug here, or some setting I have is incorrect.

Is there a special way that cell UIWidgets need to be constructed or UITable needs to be organized for this to behave as expected?

Currently in this project we have:
  1. UIScrollView
  2. Transform: 0,0,0
  3. Clipping: Alpha
  4. Offset: 0,0
  5. Center: 0,0
  6. Size: 300, 300
  7.  
  8. Table Cell UIWidget
  9. Transform: 0,0,0
  10. Pivot: Center, Center,
  11.  


After execution the Table Cell UIWidget's transform becomes 150, -50.

13
Email sent thanks.

14
I get the same odd behaviour regardless of whether I include the correct anchors you suggest or no anchors at all.

Is this behaviour of the table appearing to the side the expected behaviour that you designed? If so I am surprised as it is not obvious that it should behave in this fashion.

If this is not the desired behaviour, and this is a bug, then I think you should attempt to recreate the problem in a basic scene using the hierarchy I have shown as it appears that I am not the only one that is seeing tables work this way.

15
The table script needs to go below the scroll view. You can't place it on the scroll view itself.

Unfortunately moving the UITable doesn't change anything.

My scene now looks like:

  1. UIRoot (UIPanel)
  2. -->Camera
  3. --> --->(UIPanel)(UIScrollView)
  4. --> ---> --->(UITable)
  5. --> --> --> -->(TableCell)(UIWidget)(UIDragScrollView)(BoxCollider)
  6. --> --> --> -->(TableCell)(UIWidget)(UIDragScrollView)(BoxCollider)
  7. --> --> --> -->(TableCell)(UIWidget)(UIDragScrollView)(BoxCollider)
  8.  

Pages: [1] 2 3