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 - QuantumMechanic

Pages: [1]
1
NGUI 3 Support / Upgrade questions..
« on: October 20, 2016, 08:21:13 PM »
We are in the midst of upgrading from 3.4.8 to 3.10.2 -- Yes, it has been a while.  We have run into a couple of questions.



The signature for UICamera Raycast has changed from:
  1.         static public bool Raycast (Vector3 inPos, out RaycastHit hit)
  2.  
To:
  1.         /// <summary>
  2.         /// Returns the object under the specified position.
  3.         /// </summary>
  4.  
  5.         static public bool Raycast (Vector3 inPos)
  6.  

How do I determine what object the raycast hit?


UIPanel's no longer has a hard clipping option.  What's the correct way to accomplish a hard clip with texture clipping?


Is there a new equivalent to the formerly available UIPanel.onChange?

Seems like there are a lot of nice new features to play with.  Any hidden gotchas for folks who have not upgraded for a while?

2
NGUI 3 Support / Re: Issues upgrading to v3.5.4 from 3.4.8...
« on: March 26, 2014, 12:57:15 PM »
Thanks for you answers.  I wasn't aware that BetterLists ToArray() was calling Trim() -- but I understand why it needs to and that explains the new treatment of draw calls.  This optimization reduces the number of allocations not the amount of memory allocated and gives us better performance.

I will code the Update loop as you suggested.

Any thoughts beyond the DrawBuffer arrays as to why memory might have increased between the two versions of the library?


3
NGUI 3 Support / Issues upgrading to v3.5.4 from 3.4.8...
« on: March 24, 2014, 09:51:42 PM »
Friday we upgraded from 3.4.8 (with the trim change that was posted in the forums to reduced memory) to 3.5.4.  We were hoping that the note below would result in less memory use.

3.5.4
- NEW: Cached buffers are now per-draw call rather than global, reducing memory allocations.

However, our experience is that when comparing 3.5.4 with 3.4.8 on the same code base, our memory allocations has increased by a couple of megabytes.  Is there something else that was added that might explain this? 

Looking over the changes, I am not sure how moving the verts, norms, uvs and tans from static lists in UIPanel to instance based lists in UIDrawCall is beneficial.  It would seem to be that under the old system, if I had a panel with three draw calls -- one with 1000 verts, one with 500 verts and one with 250 verts -- I would have one allocation for 1000 verts.  Under the new system each draw call would have their own allocation and thus I would allocate memory for 1750 verts.  There is probably something subtle I am not understanding here.

Also there is a comment in the change log for 3.5.2

 DEL: Removed UICamera's OnInput event as it wasn't being used (as it wasn't reliable).

We were using the OnInput event to enable and disable buttons based on when the entry in the input box was valid.  Since we have multiple input boxes on our screen, we would catch the event -- ignore the parameters and check all the input boxes on screen to see if we could enable to submit button (was it the parameters that were unreliable?).  What would be the correct way to structure something like that now that OnInput has been removed?

4
NGUI 3 Support / MakePixelPerfect on SlicedSprites
« on: April 10, 2013, 09:59:16 PM »
  1.         override public void MakePixelPerfect ()
  2.         {
  3.                 Vector3 pos = cachedTransform.localPosition;
  4.                 pos.x = Mathf.RoundToInt(pos.x);
  5.                 pos.y = Mathf.RoundToInt(pos.y);
  6.                 pos.z = Mathf.RoundToInt(pos.z);
  7.                 cachedTransform.localPosition = pos;
  8.  
  9.                 Vector3 scale = cachedTransform.localScale;
  10.                 scale.x = Mathf.RoundToInt(scale.x * 0.5f) << 1;
  11.                 scale.y = Mathf.RoundToInt(scale.y * 0.5f) << 1;
  12.                 scale.z = 1f;
  13.                 cachedTransform.localScale = scale;
  14.         }
  15.  

I don't understand the intention behind the way MakePixelPerfect calculates the scale of a sliced sprite.  It appears to be trying to ensure that the sliced sprite has an even scale.  Our game dynamically scales a sliced sprite from a scale of 1,10,1 to a scale of 30,10,1.  To make sure that the sprite looks clean, we calculate the scale and then apply MakePixelPerfect.  This gives a somewhat unexpected result.

Looking at the x component only, since the other components stay constant.

For an x scale of 1:
the x value is halfed making it 0.5.
then Mathf.RoundToInt rounds it to 0 (values exactly halfway between two integers are rounded to the nearest even integer). 
Then the 0 is shifted left by 1. 
Resulting in 0

This generates a LogError -- Scale of 0 is invalid! Zero cannot be divided by, which causes problems. Use a small value instead, such as 0.01

for a x scale of 3:
the x value is halfed making it 1.5.
then Mathf.RoundToInt rounds it to 2 (values exactly halfway between two integers are rounded to the nearest even integer). 
Then the 2 is shifted left by 1. 
Resulting in 4

This creates a sprite that is one pixel wider than the original scale requested.

Its possible I am not understanding an underlying assumption for sliced sprites.  Can you clarify whether this is intended behavior?  My initial expectation is that it would have done something like:

scale.x = Mathf.Floor(scale.x + 0.5f);  // round scale to the nearest hole number, if scale is exactly half -- round upward.



5
When attempting to dynamically set the Atlas and SpriteName of a UISprite it doesn't seem to be working.  Setting the atlas seems to work, but setting the spriteName seems to fail.

Sample Code:

  1. private var m_DynamicGameObject:GameObject;
  2. private var m_Sprite:UISprite;
  3. public var m_Panel:UIPanel;
  4. public var m_Atlas:UIAtlas;
  5.  
  6. function Start () {
  7.     m_DynamicGameObject = new GameObject();
  8.     m_Sprite = m_DynamicGameObject.AddComponent("UISprite");
  9.  
  10.     m_DynamicGameObject.transform.parent = m_Panel.transform;
  11.  
  12.     m_Sprite.atlas = m_Atlas;
  13.     m_Sprite.spriteName = "in_golfball_bu_no"; 
  14.  
  15. }
  16.  

I Suspect the problem is in line 110 of UISprite.  UpdateUVs is only called if mSprite is not null, but mSprite is set to null two lines above.  Removing the if check and just calling UpdateUVs seems to correct the problem.  Code snippet from UISprite below for easy reference.

  1.                 set
  2.                 {
  3.                         if (string.IsNullOrEmpty(value))
  4.                         {
  5.                                 // If the sprite name hasn't been set yet, no need to do anything
  6.                                 if (string.IsNullOrEmpty(mSpriteName)) return;
  7.  
  8.                                 // Clear the sprite name and the sprite reference
  9.                                 mSpriteName = "";
  10.                                 mSprite = null;
  11.                                 mChanged = true;
  12.                         }
  13.                         else if (mSpriteName != value)
  14.                         {
  15.                                 // If the sprite name changes, the sprite reference should also be updated
  16.                                 mSpriteName = value;
  17.                                 mSprite = null;
  18.                                 mChanged = true;
  19.                                 if (mSprite != null) UpdateUVs(true);
  20.                         }
  21.                 }
  22.  

6
NGUI 3 Support / Re: Sliced sprites
« on: November 07, 2012, 07:01:18 PM »
Thanks for the reply. 

The Sliced Sprite seems to work fine as long as I am displaying the texture at the same manual height that it was created for (640).  However, when displaying the texture at a lower resolution (in my case on a 3GS at 320 height), the left and right edges of the texture do not remain 1 pixel wide -- depending on where I position it and how I scale it the borders are either drawn as 1 pixel, 2 blurred pixels, or not drawn at all.

Looking at the code, it seems to do all of its logic at localScale, and I don't understand how that compensates for the resolution which appears to be applied at a later time.

In other words, if I had an 8x8 sliced sprite created for a Manual Height of 640 which was a solid blue box with a 1 pixel white outline around it and I set it's top, bottom, right and left border to 1 pixel.  If I took that sprite and drew it on a 3GS (320 height), I was hoping that the system would draw a 4x4 box maintaining the 1 pixel outline around it.  Instead, it appears that depending on the positioning of the sliced sprite on the screen the outline on each edge can either be 1 pixel, 2 blurry pixels, or no pixels and calling makePixelPerfect it doesn't seem to help because it makes it pixel perfect at local scale.

Am I misunderstanding how this works?

7
NGUI 3 Support / Sliced sprites
« on: November 05, 2012, 07:01:30 PM »
Hi all,

My company is new to using NGUI so please forgive me if this has been answered before.  (I did a search for sliced sprites but didn't come up with anything that helped). My understanding of a sliced sprite is that the border region should not be scaled.  However, this doesn't appear to be the way it is working for me.  My case is:

I have a UI Root setup with a manual height of 640, minimum height of 320 and a maximum height of 1080.

I have an 8x32 sprite which is a solid blue except for a 1 pixel wide bar on the left and right edge of the sprite.  I have set the 9 slice sprite to have a 1 pixel border on the left and right. 

When I scale this sprite, in its native resolution (960x640 iOS wide) everything works fine.  But when I render this sprite in (480x320 iOS wide) and scale it the left and right edges flicker on and off.  This seems contrary to the behavior I would expect.  I would expect the left and right edge not to scale (remain 1 native resolution pixel wide) and the center to scale.

This leads me to the following questions:

1) Is what I am seeing a bug or is it intended behavior?
2) Is there a way I can set things up to get the behavior I am interested in?

Pages: [1]