Making GUI resolution independent


28-11-2007 00:10:22

Hey guys,
Recently looking at QuickGUI demo I noticed something - it is no longer resolution-independent, i.e. as you change from say 1024 to 1600 the screen layout differs greatly.
Previously, however, when sizes were in 0.0 to 1.0 (i.e. screen space %) this was not the case. So, I am just wondering how do you go about making a unified screen?
The solutions that pop to my mind is making like 5-6 size versions of GUI, and by determining the resolution applying the respective template. But that seems a bit messy, especially with the bottom right corner, which will look differently even with similar resolutions.


28-11-2007 00:20:01

I think the best approach is simply to get the bounds of both Height and width of current configuration and if a widget is set to be beyond this, make it come back, this follows a min/max settings and will greatly reduce errors on the programming part. Of course we should also have to choice of putting stuff on the screen based on % of parent, and size in % of parent, so that if the parent is resized then all the sub widgets gets automatically resized. If you have not checked the C# tools and their properties it would be a great place to start for resizing code.


28-11-2007 00:45:25

Already supported. 8)

Use Vertical and Horizontal Anchoring to achieve relative position and size. In order to maintain a relative size, you have to anchor left_and_right, as well as top_and_bottom. You can do one, both, left/right/top/bottom only, or none.

One important thing to note is that you have to let the GUIManager know when the viewport has been resized, because I can't really auto detect that. :P All this does is scale the Sheet, since the Sheet is always the same size as the viewport. The rest is done with anchoring.

I always test the demo at 800 x 600, but you're right, it probably looks a looot different at higher/lower resolutions. I guess I could make everything relatively sized.. :P


28-11-2007 01:14:59

That's great to hear then! Maybe using anchoring in the demo is indeed a good idea, seeing something in practice is always better!


28-11-2007 02:05:03

Why not make the manager subclass WindowEventListener and implement virtual void windowResized(RenderWindow* rw)
The only actual thing that is needed is to have the name of the rendering window or a pointer to it.

Just look at exemple frame listener line 125.


28-11-2007 02:48:52

The viewport may not always be the same size as the RenderWindow, so I wouldn't want to make that assumption. Otherwise it would have been a good idea. :)


28-11-2007 03:14:38

And after all, pretty much every time the viewport gets resized, there's nothing stopping you from adding the extra line to inform QGui about the size change. Although it still seems, that it's best to manually pre-create 2 or 3 versions of the GUI (like one for 4:3, one for 16:9 and one for 16:10, and also maybe make like a 800-600 and 1920-1400)

P.S. hotdot, nice avatar :)


28-11-2007 03:19:21

Yah, you might want a few skins, otherwise it could look stretched. Or just use high res textures, I don't know. I hope I don't resort to stretching in my own project, I really hate the limited view I get in Warcraft III. And I bet it's because of the low end Pentium 3/integrated Intel video cards that determined the viewing area. :(


28-11-2007 03:36:36

Maybe. But I bet they simply were old fashioned and didn't want to properly support all the resolutions. Well, Warcraft was, is and will be damn popular despite all their "glitches".


13-12-2007 20:29:51

Hmm... I was wondering about setting things relative to the size of the screen and came across this thread. The anchoring doesn't really allow you to make a truely resolution-independent GUI.

For example, I am trying to make a simple intro screen with some buttons next to the logo. The background image will be scaled to fit the screen, and I want my buttons to scale with the background so that you couldn't even tell they where not part of the background. Anchoring just won't work in this case.

I quite like the method used in CEGUI, where you can specify both pixel coordinates and/or screen coordinates. The way it was implemented was quite confusing but the idea behind it is quite nice.


13-12-2007 20:53:04

Anchoring just won't work in this case.

I don't see how it won't work. Can you provide a screenshot maybe? Anchoring idea is taken from Visual Studio window properties.