Sign in to follow this  
Scythen

UI elements how to deal with resolution and aspect ratio changes?

Recommended Posts

Hi all, I’m curious how user interface systems deal with resolution changes and in particular aspect ratio changes. I recently started working on my own UI system and I find this to be one of the most challenging problems I’ve had to deal with. I started by using normalized coordinates for everything but soon found that changes in aspect ratio caused undesirable stretching of the UI elements. I also tried other ways of scaling the UI elements based on the difference in aspect ratio but that caused other issues when an element needed to remain at the bottom or right edge of the screen. I also though of requiring different layouts per aspect ratio but that seems ridicules to me. So, is there some common way of dealing with this?

Share this post


Link to post
Share on other sites
My T2 program allows the UI to be stretched to any shape or size. I would say it looks OK and works fine but is far from perfect however as it is just impossible with images to get them to look good streched at wildly differing aspect ratios. What does work well in T2 is that I use a coordinate system (1000,1000) that is then matched to the current window size so UI elements do keep their positions well. For the text I actually load a series of fonts of differing sizes and select the one closest to required. I think to make it look really good you would also need a series of graphics that could be selected on size and perhaps ratio.

Share this post


Link to post
Share on other sites
Most good ones I've seen use a relative coordinate system, 0.0 to 1.0 of the screen or to the containing control. I personally use an event system to cause the elements to adjust when the one they're based off of changes.

Share this post


Link to post
Share on other sites
Right, using normalized coordinates (0-1) keeps the controls positioned correctly when resolution changes and the aspect ratio stays the same.

Switching to wide screen say 1600x1024 causes the UI elements to stretch horizontally since the aspect ratio is now 1.5625 not 1.3333 that the UI was created in. So, even though elements are in somewhat correct positions squares are now rectangles and circles are now ovals.

This stretching is what I want to avoid if I can.

Share this post


Link to post
Share on other sites
Really, it's not possible - either you stretch things or you make things wider - there's no other way around it. Perhaps taking a web-like view of it will help, positioning things relatively instead of absolutely.

Share this post


Link to post
Share on other sites
Quote:
Original post by Scythen
Right, using normalized coordinates (0-1) keeps the controls positioned correctly when resolution changes and the aspect ratio stays the same.

Switching to wide screen say 1600x1024 causes the UI elements to stretch horizontally since the aspect ratio is now 1.5625 not 1.3333 that the UI was created in. So, even though elements are in somewhat correct positions squares are now rectangles and circles are now ovals.

This stretching is what I want to avoid if I can.


Since you know the aspect ratio, why don't you take advantage of this to build your UI elements? You don't have to speak in pixels or in percent - just invent a new vocabulary (for example "ui units" (uu)) and set this rule:
* 1 vertical uu (vuu) = 1 pixel
* 1 horizontal uu (huu) = 1 vuu * aspect ratio (screen_width / screen_height).
Then your dialogs will always have the same aspect ratio - it will not depend on the screen settings.

Regards,

Share this post


Link to post
Share on other sites
The way .NET makes it simple is this: have the option to dock components to any combination of sides of the container and give a distance they are docked at. When the container (usually a window) stretches, the docked elements move and expand and shrink as necessary. Buttons grow larger and smaller but keep text centered, etc. Then, to do relative scaling, other containers you can dock to your window are offered that will keep their n children in columns or rows of size of 1/nth of the container. By combining these two, you can get either stretching or movement and it can be absolute or relative.

Share this post


Link to post
Share on other sites
Out of curiosity, why are you changing your UI to match the resolution and aspect ratio anyway? I can't stand when games do that. When I set my resolution higher, I want the UI to take up less space on the screen.

If you insist on doing it, the best I could recommend is having a function in your base UI object class that is called after updating coordinates and such to recalculate the real coordinates and size based on the current resolution and aspect ratio. In this way, it should remain transparent to your actual control-specific code and just happen automatically in the background as it were.

Share this post


Link to post
Share on other sites
The ease of handling resolution / aspect ratio changes also depends on the sort of project. A 2D game that makes extensive use of GUI will always have more of a problem dealing with changes because they often rely on quite a precise layout of GUI.

GUI skins always look worse when scaled, and I have found that isolating the positioning code and then writing seperate routines to handle each of the common resolutions to be the only good way to handle this. This method also means that you can take advantage of larger resolutions by making larger some controls that wont be effected by stretching (ie tilemaps).

Alex

Share this post


Link to post
Share on other sites
Scaling based on resolution is probably a good thing in the long run... There's nothing more annoying than getting a video card that can run a game at 2560x1920, only to find out that you'd need a microscope to read the text on the tiny buttons you can't even hit with the mouse unless you lower the sensitivity so much that it takes you ten seconds to move the cursor from one side of the screen to another. Consider that just ten years ago the state of the art in 3D games was 320x200.

Getting a GUI to work with any resolution and aspect ratio can be hard though... An interface that wraps around the whole screen is the worst case. A horizontal or vertical panel is a lot easier to deal with as you only need to think about one dimension when scaling.

Share this post


Link to post
Share on other sites
Hmm, this is actually hard to define, because I too like to have the GUI scaled with the resolution, but not in all games, since in some I actually find it much better to have a smaller GUI, when I run at a higher resolution.
So maybe you should make an option "Scale position" / "Scale position and size" or something like that?
Of course, the easiest way would be just to choose one, stick with it and stop wondering about this, which probably also makes the best decision in this case...

Share this post


Link to post
Share on other sites
Great, lots off good input here.

Quote:
Original post by Delfi
you can just simply center the whole GUI to the screen on widescreens...


Just centering the GUI would end up with large areas to the left and right of the GUI where you would see either nothing 3D game content, or maybe an image or something. Definitely not the result I want.

I definitely want to be able to scale things according to resolution. My goal is to maintain the relation between controls that the GUI designer created as best I can and to maintain the aspect ratios of the controls them selves.

Emmanuel Deloget-
I believe I’m actually doing something similar by allowing the designer to specify a “design height and width”. Basically, the design size becomes the “ui units” for the form. I’m not sure there are any real benefits to my system, in fact it may be a little more difficult to deal with.

nife-
I agree there are benefits in being able to scale the whole UI. Some people like larger buttons while others like to make the UI as small as possible. I think this can be done easily if I get the general scaling / aspect ratio thing working. I can just provide a scale function that sets a scale modifier for everything. I'm sure it can use the same code path as the system used to scale for resolution changes.

sardak-
The UI has to scale with resolution or it will be unusable at many resolutions. Take a 10x10 button at 640x480, how big is that at 1600x1200? At 640x480 it’s completely usable but at 1600x1200 it would be almost unusable. Also if it does not handle aspect ratio changes the UI starts to look very unprofessional when circles become ovals and squares become rectangles. Not to mention the issues with stretching text.

omgomghilol-
I have actually just finished my first pass at a .Net style system and its working out great so far. I've provided an anchor type that is set of each control which does exactly what the .Net anchor system does. I also added a scale value to the API that can be modified to scale the entire UI to what ever size the user likes.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this