Topics

1

NGUI 3 Support / Optimization Question

« on: February 02, 2014, 11:14:19 PM »

Hey Michael,

Just a quick question here on optimization. Were building out a tower defense game and planning on doing creeps in 2D so thought I'd go ahead and just utilize nGUI for them as well. In an effort to save pixel space so we can keep atlas sizing down (to maximize animation potential), we were planning on trimming transparency from enemy sprites as much as possible.

Obviously this means there is no consistency in Sprite Size... so my question is, if I utilize the UISprite's MakePixelPerfect() method for each creep on each update function what kind of impact can I expect on performance? Obviously only having a few creeps on the screen would not be much of an issue, but I'm thinking if a 100 were on screen (which is not unheard of for a TD game) there might be issues. Would you recommend taking the hit on pixel space and just standardize sprite dimensions instead?

Thanks for the advice/insight ahead of time!

2

NGUI 3 Support / Clamped UILabel in UIInput with Multiple (Reference) UIFonts

« on: September 28, 2013, 10:57:36 PM »

Hey all,

If any of you are using a reference atlas in their projects for quality settings control, then you might find this useful to know for your clamped Labels and Inputs in NGUI 3.0. I should note that this I'm using Dynamic Fonts in my project.

I specifically came across the issue with my Labels when using a UIInput. While the SD Atlas was active, I went to the trouble of reconfiguring my project's UIInput's Labels to be clamped (obviously since this is the necessary overflow type for single line input box's labels). The issue I came across was that if the Label's height was set to anything less than that of the current Font's size, then it would fail to display. Obviously this presents a huge problem if you intend to incorporate text that is any smaller than the default size you created your font to be.

In order to fix the problem, a few changes had to be implemented.

First, inside UILabel's ProcessText method, where it handles the various overflow types I gave it the same functionality as the ShrinkContent Overflow type:

1.                 else if (mOverflow == Overflow.ShrinkContent && !fits)
2.                                 {
3.                                         printSize = Mathf.Round(printSize - 1f);
4.                                         if (printSize > 1f) continue;
5.                                 }
6.                 else if (mOverflow == Overflow.ClampContent && !fits)
7.                 {
8.                     printSize = Mathf.Round(printSize - 1f);
9.                     if (printSize > 1f) continue;
10.                 }
11.  

Now, perhaps my own particular settings and preferences are outside the norm, but I can help but think that many of you have probably had to adjust not just the Label's width and height, but also its transform's scale to get the text to display precisely the way you want it to. Seldom is a font naturally perfect. That being said, it needs to be pointed out that UIInput doesn't account for the Label's local scale when adjusting its position/anchoring for the Label. So UIInput's UpdateLabel method needs to be updated:

1.                         pos.x = mPosition + label.width;
2.                        
3.                         // If the label's local scale is not 1, then its position should be changed in accordance to its current scale
4.                         if (!label.cachedTransform.localScale.x.Equals(1))
5.                         {
6.                             pos.x = mPosition + (label.width * label.cachedTransform.localScale.x);
7.                         }
8.  

Finally , inside of UIFont, the glyphWidth must be updated to reflect the comparative size of what your standard definition atlas' pixel size is vs. your other atlas' pixel size. How you go about this is up to you, though I would recommend creating a static reference to the standard pixel size of your current display. This should be updated in UIFont's GetEndOfLineThatFits Method:

1. #if DYNAMIC_FONT
2.         else
3.         {
4.                 if (mDynamicFont.GetCharacterInfo(currentCharacter, out mChar, mDynamicFontSize, mDynamicFontStyle))
5.                 {
6.                     // Check to see if the current Font is the Stand Definition or High Definition Font and have it account for scaling
7.                     if(!DisplaySettings.isHD)
8.                         glyphWidth += (int)mChar.width;
9.                     else
10.                         glyphWidth += (int) (Mathf.Round(mChar.width * 0.5f));
11.                 }
12.         }
13. #endif
14.  

I'm sure there is a MUCH better way of going about all of this. I don't pretend to be an expert coder, but it gets the job done for now. Hope this helps someone for the time being!

3

NGUI 3 Support / HD/SD Atlas Sliced Sprite Scaling Issues

« on: September 28, 2013, 07:07:03 PM »

Has anyone else experimented with HD/SD atlases in NGUI 3.0? I'm having some serious issues with how scaling is working with certain sliced sprites!

For instance, I have a border sprite that is 100x100px in my HD Atlas. Similarly, its 50x50 in my SD Atlas. My HD Atals pixel size is set to 0.5, while my SD is set to 1. This border sprite has a 32px padding on my HD and a 16px for my SD. It displays perfectly while in SD mode, but when displaying at HD while the overall sizing of the Sprite is the same, the display is completely wonky. From the way it looks, I would say its as if the pixel sizing of the Atlas is not taken into account for the non-repeated area of the sliced sprite... the non sliced area looks grossly oversized.

Before anyone asks, I have confirmed that the UISprite's in question are all set to the reference atlas, which I've also confirmed to be switching between atlases correctly. This problem is currently project wide so its certainly not a problem of having the wrong Atlas referenced.

Anyone else seen anything similar in their own projects?

4

NGUI 3 Support / 3.0 UIInput Select on Tab Function Broken?

« on: September 28, 2013, 03:46:56 PM »

Hey Michael,

I'm having some strange issues after updating getting UIInput's Select on Tab function to actually select the object when hitting Tab. Specifically, when selecting another UIInput after hitting tab on the "previous" UIInput. They're set up correctly, the next UIInput is definitely the targeted GameObject on the UIInput control, but when hitting tab it's as if the key event is not registering at all...

Just want to see if you can confirm this problem on your side. Thanks again!

5

NGUI 3 Support / UIPanel Widgets List removed in 3.0?

« on: September 26, 2013, 03:27:13 PM »

Hey Michael,

I was just curious-- was it intentional to remove the widgest list for the UIPanel in 3.0? This was useful for me as far some editor extensions were concerned for updating widgets on the fly using the Panel that contained them... would be helpful to know if this was just abandoned or simply overlooked. Check the docs and didn't find a reference there.

Thanks a lot!

6

NGUI 3 Support / UIRoot Automatic Disabling for Multi Resolution, Multi Atlasing

« on: November 16, 2012, 04:59:43 PM »

Hey Guys,

Forgive me if I am missing something here-- this is a bit of a foray for me into the whole world of proper UI design and universal setups-- but after reading through and watching all your tutorials Aren I haven't been able to definitively answer a question thats been on my mind regarding Universal UI design for multiple resolutions and atlas qualities.

So, first of all, Id like to precursor the question with a few variables that are specific to what I'm doing (this may or may not completely invalidate the question, but as far as I can tell it doesnt). I have a primary nav bar at the top of the screen (designed for use in landscape) that fills the entire area.  Given the height, it only takes up 15% of the entire screen's height, agnostic of whatever the total height in pixels may be.

When provisioning atlases for this setup, it makes sense to me that based on the actual pixel height to switch these dynamically... however (and this is where my question comes in) what does NOT make sense to me, is why it would be integral to turn off automatic scaling for the UIRoot?  Why is this necessary if you can dynamically switch out Atlases purely based on the pixel height already, and (likely) use most of what is in these atlases at pixel resolution that are close to its size (so if designed at 1280x720 also using it at 1136x640)? 

To make this more clear, let say if you were viewing this UI on the galaxy S3 with a resolution of 1280x720 or on an IPhone5 with a resolution of 1136x640 from the way I see it you would want to use the exact same Atlas for both (the HD Atlas for instance).  As there are many resolutions out there that fall into the 16x9 aspect ratio it seems to me that preserving the Automatic scaling of height would make this easier to manage and to implement as a Universal UI instead of disabling automatic scaling and designing it for manual heights or changing the height dynamically through code (which, as far as I can tell, is exactly what automatic scaling is already doing).

Once again, please forgive me if my ignorance is the "true" answer to this question but I've been struggling to find the solution to this that makes logical sense and have drawn up short.  Thanks in advance to help and guidance.

And of course, thanks for NGui.  This has been a huge help in prototyping and making my game so far, very thankful for the work you've put in Aren.

chuk2bp