Game Development Community

iPad Retina display GUI weirdness

by Gary Myers · in Torque 2D Beginner · 02/17/2014 (8:27 pm) · 7 replies

I was running the Sandbox on my iPad 3 and noticed that the Sandbox controls (like the pause, reload, etc. buttons) are small - meaning they aren't scaling up to the 2x size. The overlay itself is tied to the bottom quarter (no longer full screen with Retina).

The Log screen does fill the whole screen but it displays some weirdness as well. The console line is still at the 30px height while the Hide Log button adapts to the Retina screen and is shown at 2x effective resolution (so having the same "footprint" as on a non-Retina iPad). The toolbox window has its own issues as well. I'll try to take some screen-caps soon.

Any thoughts? If I were to build a GUI, do I check the resolution and use a retina gui.taml in these cases?

#1
02/18/2014 (4:50 am)
The Sandbox demo was originally designed for desktop, then slightly modified to work for touch devices (buttons to scroll instead of scrollbar). Unfortunately, the GUI sizing is tied to the game resolution. If you want to have a larger buttons that might use different profiles on one device, but not on another, then you will need to go with your proposed solution. Load a different GUI file based on the device and resolution.
#2
02/18/2014 (7:33 am)
OK - thanks. I figured that would be the case. Maybe I'll try to go with a GUI extension using a simple springs and struts mechanism to handle the resizing on different resolutions.

This leads me to my next question on GUI layout. I'm not sure what the following properties do:

HorizSizing="left"
VertSizing="bottom"
MinExtent="8 2

It looks like MinExtent is the minimum size if it gets resized smaller. I looked at the C++ code for the other two, but wasn't quite sure what they do. When does the resizing kick in?

I did look into the great GUI tutorials but they weren't too explicit.

A little off-topic, but how do I make additions to the tutorials (or other docs) page based on what I find?

#3
02/18/2014 (8:54 am)
Ok, I'm going to be kind of a jerk here - but only because I'm pointing out something that is actually pretty easily overlooked. The T3D documentation has a pretty extensive reference section - in the left pane, click the Reference Guide tab, then open Modules->GUI and click on Core Controls. The GuiAlignmentType, GuiHorizontalSizing and GuiVerticalSizing enumerations are documented (rather sparsely) on this page. The "jerk" part is that, even though there is documentation the behavior of these settings is not clear or intuitive for most people - though once you get a feel for them you'll go "oh, I see - I guess...."

And a tidbit - the GUI system is almost unchanged in functionality (TAML not withstanding) between the various Torque flavors, so even GUI tutorials from TGE are mostly still relevant.
#4
02/18/2014 (9:45 am)
Thanks for the link Richard. I'll take a look. That's a good tip on the cross-product documentation - didn't realize there was that much overlap.
#5
02/18/2014 (12:23 pm)
For Frozen Synapse we ended up using retina resolution with a 1024x768 coordinate system for rendering - that is all the gui elements were internally scaled up 2x, while the fonts were rendered using the retina dpi and scaled back down to fit the smaller coordinate system.

Unfortunately simply scaling the elements and/or using different gui files didn't work well since if for example you increase the font point size you'll usually get slightly different kerning values and hinting which can make the gui look completely different - not to mention it would have caused more maintenance issues.

All of this required a ton of changes to the C++ code. You could probably get away with just using different gui files ;)
#6
02/18/2014 (1:05 pm)
Quote:A little off-topic, but how do I make additions to the tutorials (or other docs) page based on what I find?

Unfortunately contributing to the docs requires jumping through some hoops. When you fork the engine, you also fork the wiki - so you end up having your own personal copy which you of course have write access to. There you can change an existing guide or write a new one using Github's web editing tools. When finished, submit an issue with a link to your content and a steering committee member can then copy/paste it into the official wiki.

We're still focused on getting 3.0 out the door, but improving the documentation itself and how the community can contribute to it is on the to-do list.
#7
02/18/2014 (4:28 pm)
@James thanks for the insight. I will try the GUI files approach first :) I am playing around with combining UIKit on top of the glView as an alternative.

@Mike thanks. Based on that I will wait final 3.0 release before forking/submitting a pull request.