NGUI 3.0.9f7 multiplatform app

[Tripwire]

I recommend you fix that warning you see on your UIPanel about two panels sharing the same depth value.

It's best to tween to a point that you know is off-screen on both devices. Scroll views (clipped panels) move by adjusting their position and adjusting the clipping region's offset by the inverse of the position adjustment. If you want more predictable results, make the panel be anchored to a widget, and tween the widget.

I'll fix the depth issue. How would the hierarchy look like then? Like this?:

UIRoot
-Camera
--Panel
---Tween Widget
----Label01
----Label02
----Sprite01
----Sprite02

So I tween the widget, instead of the panel?

[ArenMook]

UIRoot
- UICamera
- UIWidget
-- UIPanel (anchored to its parent widget)
--- Label 1
--- Label 2
...etc

[Tripwire]

UIRoot
- UICamera
- UIWidget
-- UIPanel (anchored to its parent widget)
--- Label 1
--- Label 2
...etc

So the WidgetContainer should be on the same hierarchy height as the UICamera? Not as a parent of the UICamera?

I've setup everything but now it's not scaling correctly anymore to iPhone 4 resolution for instance. 640x1136 to 640x960.

Here are my settings:
-UI Root
--UI Camera
---WidgetContainer (not anchored)
----Panel (anchored to the widgetContainer)
-----Label01 (anchored to the panel)
-----Label02 (anchored to the panel)
-----Sprite01 (anchored to the panel)

It doesn't really matter if I set the WidgetContainer on the same hierarchy height as the UI Camera.
Also I don't really know how to setup the WidgetContainer, should the X and Y values be the values of the screen?

[ArenMook]

You need to put an anchor on the widget container as well, or it won't scale. Tween the widget container.

[Tripwire]

You need to put an anchor on the widget container as well, or it won't scale. Tween the widget container.

Hi ArenMook,

I added an anchor on the container and set the target to the UIRoot but it's still not scaling when I change from iPhone 5 to iPhone 4. Here's my widget container:

[ArenMook]

You haven't given it a reason to scale. You're using absolute values. They don't scale. If you want it to scale, use relative values -- change the "Target's Center" to be "Custom" and adjust the relative field (or slider).

For example to make it use 30% of the screen's dimensions, anchored to the center:

Left: 0.35, 0
Right: 0.65, 0

0.35 = 0.5 (center) subtracting half of desired width (30% = 0.3 / 2 = 0.15)

The ", 0" after is the absolute value. You have it set to -50 and 50. Keep it at 0 if you want it to be 100% based on the parent's dimensions without any offset.

[Tripwire]

Really nice it seems to be working now. I saw what I did wrong, I forgot to set the anchoring on the container to left and right, top, bottom. Then it worked!

The only thing I don't get is, when switching from iPhone 5 to iPhone 4, why the width = 760 instead of 640 which is the width of the iPhone 4.

EDIT:
One thing is still not clear for me, how do I anchor a WidgetContainer that is offscreen (say position 640)? If I anchor it now it screws up the whole panel which is a child of the WidgetContainer

You haven't given it a reason to scale. You're using absolute values. They don't scale. If you want it to scale, use relative values -- change the "Target's Center" to be "Custom" and adjust the relative field (or slider).

For example to make it use 30% of the screen's dimensions, anchored to the center:

Left: 0.35, 0
Right: 0.65, 0

0.35 = 0.5 (center) subtracting half of desired width (30% = 0.3 / 2 = 0.15)

The ", 0" after is the absolute value. You have it set to -50 and 50. Keep it at 0 if you want it to be 100% based on the parent's dimensions without any offset.

[ArenMook]

To anchor something off-screen, you have to adjust its anchor so that it's effectively off-screen.

[Tripwire]

To anchor something off-screen, you have to adjust its anchor so that it's effectively off-screen.

Hi ArenMook,

I finally got it all working thanks to you! Thank you so much for helping me out with this problem. I would advise you though, to create a detailed tutorial about multiplatform GUI's and NGUI. Maybe create a sample, with tweening and off screen panels etc. Again thanks for the help!

[bluedot]

Ok, I'm essentially following the same mistakes and having a LOT of trouble understanding how things can be "anchored" and then tweening the panels that group them, etc... Finally found this thread because I've been pulling my hair!

I have yet to understand all the steps you followed to solve it, Tripwire, but am reassured by your last post!

ArenMook, I agree with Tripwire that a tutorial addressing a standard use case for multi-platform/mult-resolution/multi-aspect ratio on mobile platforms would be ideal and super helpful to newbs like myself.

Something that demonstrates sprites that "snap" to the edges of the device with some level of offset (what the anchors achieve) yet are sized proportionally for different resolutions (what UI Root settings achieve) and can be grouped to animate as a unit to bring them on and off-screen based on actions (presumably a tween on a panel or widget that is a parent which was triggered by a button) would greatly enhance the understanding of how these items should be organized and configured.

I realize that once you get the "aha" moment it's probably all trivial, but if people are making the mistake first it means it's not intuitive enough. From a framework perspective, ArenMook, I am not sure what can be done to simplify the process and make it intuitive out of the box. It might not be possible if it clashes with the general philosophy behind some choices, otherwise perhaps something to consider for a future version?

[jtfrench]

Hi ArenMook,

I'm a fan of NGUI but there absolutely needs to be a full-written programming guide on how to anchor/position/handle multiple resolutions --- or pretty much everything. I created an account today for this purpose because it's just too big of an issue for me to remain a forum lurker for.

NGUI needs a complete programming guide.

It needs to not just be a video. Videos are great, but some concepts are better understood when described in detail in prose, and then we can read it at our own pace. Following the videos half the time I'm fighting with the YouTube UI to center in on whatever is the particular checkbox that you're talking about, meanwhile missing half the point and having to rewind. This gets frustrating and feels like time/energy wasted (including wasting your time making those videos, though I guess they might seem easier than writing something more substantial).

I've been using NGUI for years now, have followed your success (kudos to you), and have seen it evolve. I think it's about time you do a real set of programming guides --- not just class references, and not just videos, not just examples, and not just a few more detailed forum posts writeup here and there about some topics, but a definitive programming guide.

As a former tech writer for Apple and a long time customer of yours, I can tell you that it will alleviate a bunch of support issues and your audience demands this. Just think about how many developers today are trying to do what OP posted:

+ Develop for 3.5" iPhones
+ Develop for 4" iPhones
+ Develop for who-knows-the-hell-what" Androids

...and no dedicated NGUI programming guide that's updated to the latest version of NGUI? And you pulled in over $300k? Perhaps some more of that could go to documentation. Plus one of your greatest gripes in your (pleasure to read!) forum post about your unplanned for successes with NGUI was just how much of a beast it came to support. First off, I applaud you as this is a great beast to have --- but also this beast is your own creating — more so if you do not resolve the documentation problem in a more thorough approach. You can reduce the barrage of "n00b" questions that go on and on before a solution is finally resolved (only to have a new poster come the next day with the same question and unable to extract the same answer) by just giving your ass-kicking UI library & it's adoring fans the documentation they all deserve.

And to not be one to point out problems and not have a solution: I would be willing to work on this with you if you need some help. As again stated, I wrote guides on fairly complex stuff such as kernel convolution and vector processing for Apple back when Steve was there. Here's an Apple-approved Programming Guide (different from a Class Reference) that I personally wrote. https://developer.apple.com/library/mac/documentation/performance/Conceptual/vImage/Introduction/Introduction.html

You can even see my dog Cookie in it

Anywho, hopefully we see some better documentation soon because I am going through too many hoops to get my UI to render correctly since the new 3.x stuff. Looks like I'm definitely not alone here.

Your's truly,
jtfrench

[ArenMook]

@jtfrench: Most people using Unity aren't technical, so overly technical documentation would be over their heads -- which is why videos are a great way to convey the basic information. For developers, if http://www.tasharen.com/forum/index.php?topic=6754.0 is not enough, http://www.tasharen.com/ngui/docs/annotated.html has the documented class list, but more importantly everything in NGUI's source code is commented with the goal of making it easy for others to understand what's going on. That said, I do agree that step-by-step written tutorials can be a good thing, and some programmer-centric things can help as well, but I strongly advise asking such specific questions under the doc thread for component you're trying to use and I'll do what I can. Documentation is an ever-evolving process, and when something is actively developed -- an ever-changing one as well.

[jtfrench]

While sure, there may be many people using NGUI who aren't technical, I doubt that's a good enough reason to not include more in depth info. The link you mentioned ( http://www.tasharen.com/forum/index.php?topic=6754.0 ) is the exact reason I posted it in the first place —perhaps for you, the creator of NGUI, you feel this covers everything, but it doesn't cover the tiny nuances which end up taking up a lot of time. I would say it's insufficient. For example, I tried figuring out the right way to do anchoring & multi-res handling in NGUI v3x, and I read that, and still couldn't find definitive answers (hence coming to the forums).

Definitely keep the videos though, as they are helpful for some people, but there's a reason why almost every other software company does *not* rely on just videos to teach programming concepts.

Telling someone to "read the source" is even less helpful, and goes against your first hypothesis that "most people using Unity aren't technical".

I think more needs to be done. I want the NGUI bible. The one doc that will 9 times out of10 have the answer to whatever operation I'm trying to do. It's your company/product so do as you will doc-wise, but I may have to switch UI libraries if it looks like there's no real urgency on your end to resolve this. I ultimately have a business to run as well, and I can't train new engineers in your software by telling them to spend hours re-winding YouTube videos and trying to get answers to each question on a forum.

Thanks though!