UI components: Scaling

Started by
4 comments, last by frob 11 years, 5 months ago
Hello,

I have made a little UI system to render UI elements (button, combo boxes etc.) in my DirectX 9 game.

Now I struggle a little bit with scaling of my components. To make my problem more clear I made a sketch:
[sharedmedia=core:attachments:12412]
Lets say I start my game windowed with resolution of 2000x1000. The red rectangle is my UI component. Now If i resize the window down to 1000x500 I guess it would be desirable to scale down the UI component proportionally.
So my algorithm could be something like this: After resize of window, resize all UI components proportionally horizontally and then vertically.

But then I have a problem when the user only applies a resize of the window in one dimension (bottom image). If I applied my algorithm the UI component would be distorted - clearly something I do not want.

So how could I implemented a solid scaling mechanism that scales my UI elements when the resolution changes?

Thanks!
Advertisement
Windows handles this with the WM_SIZING message, actually providing information on the element used to resize. An easy fix for you would be to handle horizontal and vertical scaling separately. When your window changes size, recompute the horizontal scale factor, apply it to the width of your ui elements, and do the same thing with vertical/height. Also realize, you may not want everything to be sizable. Buttons are drawn at the scales they are drawn for a reason, if you shrink them too much, you will find it hard to click, and if you grow it too much, you lose the real estate you gained by scaling the window in the first place. Text will not handle scaling much at all, especially a one dimensional scale.
have a 2 component scale + 2 component pixel offset for both position and size, which allows you to place gui elements lets say 5 pixels from any edge of the screen no matter what resolution, or keep it x pixels high but scale width with resolution.

Also allow the scales to be proportional to either the corresponding axis of resolution, OR both scale axis proportional to only 1 resolution axis like x and y.

o3o

We've handled various resolutions in a few ways.

Probably the best is to have the UI based on the corners and center lines of the screen, scaled (keeping their aspect ratio) based on resolution. A long narrow screen like you posted means there is a bigger gap between the left and right side, and the screen height is the controlling scale factor.

Another is to normalize the screen to a fixed aspect ratio, drawing black bars over the two sides that are out of bounds. The entire screen could be based on a 4:3 aspect ratio, and any other display ratio gets black bars.
@frob: Could you please elaborate your first approach a little bit more? Do you mean I determine whether I scale a component based on the smaller dimension of the window?

@frob: Could you please elaborate your first approach a little bit more? Do you mean I determine whether I scale a component based on the smaller dimension of the window?

Let's try an example.

We'll have a button bar, built as a 600x100 strip, rooted at a corner, occupying up to 40% of the screen horizontally and up to 10% of the screen vertically.


Let's start with a 640x480 screen.

40% * 640 = 256px max width
10% * 480 = 48px max height
The width is the constraining value, so the UI element scales to become a 256x42 px bar.

Let's try with a 1024x768 screen
40% * 1024 =409px max width
10% * 768 = 76px max height
The width is the constraining value, so the UI element scales to become a 409x68px bar.

Let's try with a widescreen 1680x1050 screen
40% * 1680 = 672px max width
10% * 1050 = 105px max height
... Things just got interesting ...
Neither value constrains.
So we can choose to scale, height is the constraining value so we scale up to 630x105
Or we can choose to not scale, making our 600x100 button bar full size regardless of the larger screen space.


The titles I've worked on that did this always used normalized screen coordinates. So the UI element may have the UI element's corner be rooted at (0,0) or (1,1) or some other corner, or it may have it's center point rooted at (0.5, 0.5) to be exactly centered, or perhaps a little experience shows you should be a little higher on the screen with its center point rooted at (0.5, 0.4).

All the UI elements can be specified in an XML configuration file or other scripts so designers can manipulate them. They are also named constants so it is easy to move as a batch.



Naturally this format has its own set of drawbacks; all layout systems have their own sets of pros and cons.

This topic is closed to new replies.

Advertisement