Messages

1

NGUI 3 Support / Re: Optimization Question

« on: February 09, 2014, 11:42:45 PM »

Sorry about the delayed response here guys-- but just wanted to voice my appreciation for the responses.

Cripple, its great to have the opportunity to talk with another TD Dev. I'm certainly happy and willing to have your advice as far as 2D implementation for Creeps go.

We don't have a pro license for Unity (yet), so at the moment I'd have to build my own atlases. Though, it seems sensible to me to just utilize nGui's Atlas Maker to do this easily and quickly right from Unity. However, past that, if you think performance would be improved by utilizing unity's 2D capabilities I'd certainly love to have some insight into your own process!

As for pathfinding and targeting, I'll be building those ground up myself. I've picked up a pretty good pool manager so I expect optimization to be fairly manageable. If you'd like/be willing to carry on this conversation outside of the forums here feel free to email me. Thanks in advance for the help! And thanks for the response as well Michael.   

2

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!

3

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!

4

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?

5

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!

6

NGUI 3 Support / Re: UIPanel Widgets List removed in 3.0?

« on: September 26, 2013, 03:32:45 PM »

Ha! You're too fast for me! I was actually just about to follow up that I'd looked into the UIWidets class after seeing that UIPanel had got a list for all active Panels in the scene. Thanks for the fast reply! Looking forward to delving deeper into 3.0's new features.

7

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!

8

NGUI 3 Support / Re: iTween and NGUI

« on: August 21, 2013, 11:29:57 PM »

I know this topic is loooong since dead, but for those of you who still actively use iTween in their projects I figured I'd post this. its worth noting that you should be aware that when using itween for NGUI widgets, you should always take into account the UIRoot's transform scale value. This is likely why most people are experiencing such radical positioning problems (and assuming that its defaulting to world space). Hope this helps!

9

NGUI 3 Support / Re: Why the sprite can't shows in selected window in 2.3.3d

« on: February 17, 2013, 12:42:37 PM »

I'm actually having the same problem as well. Very annoying! As for attempting to mess around with a solution, I tried adding a new image, replacing and even removing an image from the target atlas to see if upon rebuilding the atlas that would fix the issue... no luck.  If its helpful to know, I have another atlas with only 3 small images inside of it and the sprite selector is generating previews for that one just fine.  It's just problems with my main UI atlas that is incapable of generating previews. Could this be an issue where a certain threshold of images passed and the sprite selector no longer generates previews?

10

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

« on: November 16, 2012, 06:06:19 PM »

Hmm, I think, as I mentioned in my first post, that the real culprit here is my ignorance.    If I am (finally) understanding you correctly, then designing the UI at a height of 720p and using a corresponding atlas that has been built for the same dimensions, then disabling Automatic scaling and rendering the UI on a device with a smaller height (like the iphone5's 640p) according to Unity the resolution will still be the manually entered 720p, regardless of the screens actual height (in which case the overall scaling occurs automatically as discussed before to fit 720p into 640p via Unity)?

11

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

« on: November 16, 2012, 05:49:58 PM »

Well then in that case, I'm back to my original confusion.  If I am manually specifying the height as 720p, (wanting this to be a universal UI) how will I allow this to be viewed on a height of 640 and have the same visual experience?

12

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

« on: November 16, 2012, 05:36:46 PM »

Sorry Aren, bear with me for a moment here, but then this would mean disabling the Automatic setting and then desiging a UI at...say 1280x720 (corresponding to my HD Atlas), if I were to alter the manual height to 640 (for the iphone5) dynamically during runtime that it would all scale automatically (this seems counter intuitive naming considering all things, but by its definition this is true) to the same sizing constraints?  Then, past this, at certain pixel thresholds I would just switch out to the next Atlas when those pixel dimensions are hit?

Am I understanding this correctly? This makes me a bit sick to my stomach at the moment, because up to this point I have designed my UI at 1280x720, and then attached UIStretch scripts to every single Widget to make it uniformly proportional at different resolutions. If this whole time I can simply just use manual height and have this done for me automatically then I'll plan on crying myself to sleep tonight?   

13

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