Resolution switch problems on iPhone and iPad

[NianDarck]

we are doing a test in landscape mode in the ipad and the iphone, our image is set to: 1024x1024, if i put the manual height to 480 it almost look good (excellent on iphone but in ipad looks a little moved), but if i put the manual height to 1024 or 768 it looks alot smaller, why is that?, and what settings I have to change in the manual height?

[ArenMook]

If you want it to look the same, don't change the manual height.

[NianDarck]

thanks for the quick respond , now we have the manual height always to 480, but the problem now is that in the ipad3gen the GUI is look really small and in the ipad1gen and ipad2gen still moved to the left and some of the GUI its not displayed because of that problem, also in ipad3gen we have a highres texture (2048x2048) insted of the low res (1024x1024). What do we have to do so the GUI does not look smaller in the ipad3gen and don´t look moved to the left in the ipad1gen and ipad2gen?

[ArenMook]

Not sure why it would move to the left? You might want to look at your anchor setup. Try building the provided examples for different devices. Open up the first one (anchor example), change its UIRoot to use a manual height of 768, and try building that, for example.

[Nicki]

Ipad3 looks really small, because UIRoot has a default maximum height of 1024, and that checks actual screen.height, and when that's higher than 1024 it sets your manual height to that.

Check your UIRoot, it will be set to 1024.

Set the maximum height to 1000000. Then it's fine.

[ArenMook]

That will make it look smaller, Nicki.

[Nicki]

No it won't, since Screen.height is smaller than 100000. It only gets set to that, if the Screen.height (not UIRoot's Manualheight) is bigger.

He should, obviously, keep his manual height at the 480 he put it.

I actually think it's a bug - or at least it's sorta weird behavior, that it changes it to maximum even if you set manualHeight to lower than that.

[ArenMook]

The way it works is -- if the Screen.height is between min and max, the UIRoot's is treated as if there is no min/max, and the root is set to "automatic".

If the Screen.height is not within the min/max range, then the UIRoot is treated as if it's not automatic, and the manual height is Mathf.Clamp(Screen.height, min, max).

[Nicki]

It also does it if automatic is unchecked (set to manual height),  and that's exactly what's happening.

The default values of min max are something in the order of (320, 1024) and when ipad 3 comes along with a screen.height of 2048, it clamps to 1024 instead of the inspector set manualheight of 480 (or whatever number you used).

Setting the max to be higher than your screen height will ever be will "fix" the problem.

We had the exact same problem for the Nexus 10 and Ipad3.

I would argue that when you set a manual height, you don't need to clamp the activeHeight, since it should be the NGI user's responsibility to handle it. But in any case, that's what happening.

Look in UIRoot.cs under public int activeHeight, and you can see the reason.

[maik]

Hi,

I'm on the same team as niandarck.

We solved the problem a while ago, and the way we solved it was:

Go back to version 2.1.2
(we originally created the GUI with 2.1.2, and everything fine. Then we updated to 2.2.3 and then the problems came)

Just by doing that, with exactly the same settings, the same elements, now everything works fine.

But if we upgrade, the problems comes back (not all the positions are respected on the different devices).

The main problem here is: we want to use some of the new features of newer versions...  What can we do about it?

[ArenMook]

If you have the Pro version you can simply pick which changes you want by merging them into your repository selectively. If you don't have pro, then you have to do it all manually.

[maik]

But how can we know which features breaks the compatibility?
In the release notes does not say anything about it.

[ArenMook]

Compatibility with what? Generally if there are some compatibility issues, such as going from Unity 3 to Unity 4, it's #ifdef'd -- which is quite obvious.

[Nicki]

Maik, in general you want to be at the newest version - if there's something that genuinely breaks in the NGUI code, make a simple case that reproduces the bug and send it to ArenMook at support at tasharen.com as a zip or something like that, and he'll fix it.

Often it's your own custom code interacting with the NGUI code oddly in my experience, but not always.

[PapaWhiskey]

contemplating switching to NGUI from UIToolkit due to issues with scaling for aspect and resolution (both of which are doable in UIToolkit, just not reliably for one reason or another)...

theoretically NGUI handles multiple resolutions from what Ive seen in the forums, yet downloading the eval version and running the UIAnchor scene, it's obvious that resolution is not solved...as supplied changing the resolution on the UIAnchor sample while the build settings are set to Android, shows that there are still issues with multiple resolutions.

From browsing the forums it sounds like maintaining aspect ratio is also not supported, unless i didnt dig through enough posts.

Does the resolution switching not work in the Editor? is it not working for that sample? Is aspect ratio scaling not supported natively? (meaning I have to do it in code)...can i easily set a global scale for NGUI?

Was out most of yesterday so I'll admit I didnt read "every" post in the forums, but myself and another programmer verified multiple times that the resolution switching did not work on the UIAnchor scene...is it possible (read "get latest" on one post) that the evaluation version is "behind" the main branch and thats why there are issues?

Phil