I'm blanking on this one. I can anchor stuff on edges of course, that would make my UI resolution independent...until it changes so much that the graphics are too small. How do I scale appropriately whenever needed? How do I keep my graphics at the right proportion while scaling? I don't want them stretched if the resolution has a different proportion like 16:10 as opposed to whatever else.

Is there a true and tested approach to this? Video players show black borders because of this problem, is this not properly solvable?


First keep in mind that with rasterization there technically is no such thing as true resolution independence. With high enough magnification individual texels will start to become visible. The only solution to this is to write a vector graphics system.

That being said there are a few steps to creating a robust raster based resolution independent system: sizing, coordinate systems, and layout.

For sizing and positioning we need to use some set of units that maintain a ratio to the actual application resolution. In this case lets use inches because I'm American and you can scale elements with DPI (dots per inch). For example lets say your application is running at 800x600. Default Windows DPI is 96 so that means the application has a resolution of (800 / 96) x (600 / 96) inches or 8.33x6.25 inches.

Since you need to be able to work with, at the very least, both 4:3 and 16:9 aspect ratios how you handle your screen coordinate system gets a little bit tricky. What I recommend doing is putting (0,0) in the center of the display area (as well as windows and controls). This works well because if you put (0,0) in a corner then as that corner moves around based on resolution and aspect ratio it's going to translate all of your sprites whereas the center of the screen will always be the center of the screen no matter the device. Continuing our example with 800x600 this would result in a coordinate system that is (left to right) -4.165in to 4.165in and (top to bottom) 3.125in to -3.125in.

So at the moment you have DPI independent UI system with items that will always be at the same spot relative to the center of the screen - not quite resolution independent. Fortunately what DPI independence allows you to do is scale the UI by scaling DPI based on some heuristic. For example we can scale DPI using vertical resolution as our heuristic. If 800x600 is 96 DPI then we'll use 123 DPI for 1024x768 or 115 DPI for 1280x720.

Lastly you will need to build a layout system that handles both absolute positioning as well as relative positioning. Excellent examples of this are WPF and the web. You can specify that controls/boxes fill some % of the parent element while docking it to an edge along with many other useful automatic layout options. All of this together will result in a UI system capable of looking nearly identical across many different resolutions and aspect ratios.

To summarize I highly recommend you study WPF as it does nearly all of this except it maintains an origin at the top-left corner coordinate system and doesn't automatically scale DPI based on vertical resolution.


Generally what you'd want to do depends on the game.

One option is to have black borders if the aspect ratio (proportion) is different (probably easiest, just render to texture, then render that to screen, resizing as appropriate).

Another option is to have different render paths for different aspect ratios. You could have one for widescreen, one for 'normal'.

Yet another option is to scale things separately, e.g. make a UI message box larger or smaller depending on resolution. Whenever you need to work out where to draw to, instead of using exact pixels, do things like 0.2 down, 0.8 across, width 0.1, height 0.3. Ovbiously in this case you'd get stretching of things, although depending on how you're drawing things that could be fine (i.e. stretch a UI background, but not the text).

In terms of 3D, as long as you set the viewport up correctly you should end up with widescreen players being able to see slightly more than non-widescreen setups. (alternatively draw black borders / or stretch the view).

  • \$\begingroup\$ "just render to texture, then render that to screen, resizing as appropriate" No. That would create a really blurry and strange looking image. And what if the resolution is too low? Everything will become unreadable. \$\endgroup\$ – Tara Sep 23 '15 at 20:08
  • \$\begingroup\$ Keep reading, that's one of a few options. You wouldn't definitely get the issues you describe either (although if done simply/incorrectly then yes it would be blurry and stretched etc.) \$\endgroup\$ – George Duckett Sep 23 '15 at 20:12
  • \$\begingroup\$ I kept reading. But your answer is very unspecific. Also you definitely would get the issues i described, because you can't just render everything to a low resolution and expect text to stay perfectly readable. \$\endgroup\$ – Tara Sep 23 '15 at 20:14
  • \$\begingroup\$ I'm not saying render to a lower resolution than the target, although obviously just rendering at higher resolution would produce artifacts too. My answer could've been fleshed out too, however as there's a good accepted answer already I won't come back to this one. I did mention text rendering specifically as that's slightly different to choosing where (and how big) to draw something but it's true that was very brief and could've been elaborated on. \$\endgroup\$ – George Duckett Sep 23 '15 at 21:21
  • \$\begingroup\$ I didn't say render to lower resolution than the target either. You simply can't take the UI 1:1 and render it to a lower resolution than it was designed for (that's what I meant with lower resolution). \$\endgroup\$ – Tara Sep 24 '15 at 2:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.