Why do games usually only allow some specific resolutions, instead of allowing arbitrary window resizing? Are there any technical difficulties for arbitrary window resizing?

  • \$\begingroup\$ What resolutions do you think the graphics hardware supports? \$\endgroup\$ Commented Aug 11, 2019 at 20:38

2 Answers 2


There are plenty of games out there, some are from big studios, some use well established and battle tested tools, plenty don't. I can think of plenty of things that could go wrong when it comes to resolution.

I am leaving aside the fact that on full-screen the monitor and driver combo will have a set of supported modes (and there is no point in emulating modes), and I am also leaving aside the fact that some platforms will force the resolution (some even handle the scaling).

Motivations for a minimum:

  • Some UI elements and spacing will just break if the window size is too small. Depending on you do your layout, you could end up computing negative sizes (e.g. position an element to leave a margin to the left and a margin to the right, and then there is no room for the element).
  • Too small UI elements are bad accessibility. So you avoid your negative sizes by just scaling everything uniformly, now you can end up with too little space for texts, should you add a scroll bar? Tough luck, there is no room, gotta make that scroll bar tiny. ¡Arg! nobody can see it, let alone click it, and don't get me started on touch screens.
  • Smaller resolution come with better performance. For a competitive game where responsiveness is an important consideration, having a resolution that is too small but performs better than the average could be seen as a form of cheating.

Motivations for a maximum:

  • More pixels to draw is less performance. Although, granted, on a traditional pipeline the number of objects is the bottleneck.
  • Your textures pixelate. You can have higher resolution textures – or if your engine allows, vector graphics – at a cost on performance.
  • You have to worry about scaling up fonts. Will you allow more text on screen or use bigger text? The text could end up too small on the screen, because resolution and real screen size could change independently. This is an added difficulty.
  • When it comes to a competitive game… similarly to how a small resolution could make things harder to click, a bigger resolution could make hit-boxes too easy. Assuming the developers are using a traditional pipeline with moderately sized textures and a limited number of objects on screen, the additional resolution has a small impact on performance… then the large hit-boxes are all win for the player, and thus an unfair advantage (over players with smaller screens) in the competitive game.

Motivation to preserve aspect ratio:

  • You cannot just scale uniformly. If you choose to scale, you got to consider the aspect ratio to avoid distortions. The code is no big deal, but has consequences.
  • Since you want to avoid distortions you will scale to match one axis (often the vertical), thus, a different aspect ration would mean that a player could see more of the world than another. Perhaps that is feature, perhaps that is an unfair advantage. Sounds like something to avoid if you hope to create an e-sport. Should you add black bars?
  • That list view where the users picks whatever, it is perfect for some aspect ratios, on others it is a waste of space. On the list, unless you want distorted text, the text can only scale with the vertical, thus on a wide enough aspect ratio you are wasting a lot of space. Should it be a grid?
  • How many columns should that grid have? We need to write code to determinate how many columns, considering the width of the text, with the added difficulty of keeping the columns the same width.
  • You could flow elements instead. Now you need to figure out when to push an item to a new row. Advise: make all the elements the same size (perhaps by using an icon to represent them and dedicate a sidebar for the description of the selected item), so you do not have to deal with elements of different sizes. Thankfully we get solutions to flow text in most environments, however, remember somebody had to solve that.

Motivations for discrete resolutions:

  • If you support only a discrete set of resolutions, you do not need code to decide how to flow or to compute number of columns. Why? Because you can solve and hard-code the solutions for a discrete number of cases.
  • Not all layouts make sense. Going back to the problem of having a resolution that is too small, perhaps you could flow elements. That sidebar should be pushed to a footer if the resolution is too narrow. Do we want to handle that dynamically?
  • It can be hard to convey to user where things are if they can move around.

Extra wrench: we should let the user scale up the text and the UI elements for accessibility. Yeah, plenty of games do not have that.

We effectively need modern browsers' CSS to deal with all of it with relative ease. However, most game engines and UI tool-kits designed to integrate with games don't have tools that are that powerful. If there aren't available for the platform & engine & language combo you use... It is much easier to support a discrete set of resolutions on which we can test the game, than to retrofit content flow on a UI solution that does not support it, or roll your own. And even if you have a good UI toolkit, you still should have a minimum.

This is particularly true if you do not have developers working exclusively on the UI. Arguably you should have them, if you can afford them. Can you? How many? Perhaps you should be placing resources in making a more entertaining and fun game, in particular if you are an indie developer or a small studio. Unless the game is about resizing windows.

The flip side is when we are a big studio, have developers working exclusively on the UI, and we are making an e-sport-ish competitive game. We do not want to give unfair advantages to players such as extra performance with small resolution, or extra field of view. Nor we want players taking advantage of high resolution for ease of aiming.

  • \$\begingroup\$ "most game engines and UI tool-kits designed to integrate with games don't have tools that are that powerful" - this seems really like the gist of it. Mind you, at least most of the layouting problems you mention have more or less been solved in UI toolkits for regular applications some 15 to 20 years ago. \$\endgroup\$ Commented Aug 15, 2019 at 9:46

It’s already something of a chore to support multiple fixed window sizes and aspect ratios in terms of UI scaling, managing the visible play area (especially in some kinds competitive games), render target sizing and compositing, and so on. Just look around here at the number of questions focused on aspect ratio handling and scaling issues.

The added difficulty of an effectively infinite number of width / height combinations often doesn’t seem worth the effort as most of the time folks play games such that the game takes over the full real estate of the display.

More casual games, which may be played in non-full screen windowed mode more commonly tend to support it. But those casual games have found a more welcoming home on mobile platforms in the last decade, where it’s generally not possible to do arbitrary window sizes anyhow.

  • 1
    \$\begingroup\$ "The added difficulty of an effectively infinite number of width / height combinations often doesn’t seem worth the effort..." May I ask what are the added difficulties? \$\endgroup\$
    – Rui Liu
    Commented Aug 11, 2019 at 16:22
  • \$\begingroup\$ What I mean by that is is that hard to do for five resolutions; as you add more and more effective resolutions (because arbitrary resizing means potentially all sorts of unusual width/height combinations) that keeps creating more and more work, potentially (again, depending a lot on your game design). \$\endgroup\$
    – user1430
    Commented Aug 11, 2019 at 17:23
  • \$\begingroup\$ (And Theraot’s answer provides a much more detailed breakdown of the issues.) \$\endgroup\$
    – user1430
    Commented Aug 11, 2019 at 18:14
  • \$\begingroup\$ There's a reason Cognizer forces a particular aspect and adds black bars wherever needed to make that happen. Just not worth the hassle. \$\endgroup\$
    – Almo
    Commented Aug 14, 2019 at 14:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .