UI elements how to deal with resolution and aspect ratio changes?
Author
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?
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.
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.
Author
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.
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.
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.
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,
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.
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.
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.
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
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
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
