pouët.net

Hello,

It has been customary, when size constraints allow so, to present the user with a dialog allowing them to choose the resolution in which to run a demo or intro. As we were rewriting significant parts of our demo engine, I revisited the way we did that.

What we had been doing so far was like many other demos: on one side menu with a list of detected resolutions where the current one is pre-selected, and on the other side a menu manually filled with some typical aspect ratios. So basically what we understood the consensus to be.

This is how it looked, you've seen such dialogs countless times:





I thought there were several problems with this method. Although it does the job, the menu can be a bit messy if the machine supports gazillions resolutions. In the capture above which I just took a moment ago, there are already just too many resolutions to choose from, most of which we don't care about anyway.

But that's not the biggest problem I see. On most Windows machines I've worked with, switching to a resolution that is not the native one will make a mess of the windows that are opened. Choose 1280x720 to run a demo because it's too slow in 1080p, and after the demo is finished your browser and other programs are all over the place. That's just annoying.

Moreover, resolution is just a technical detail that is not very relevant: as long as the demo is rendered correctly and with sufficien

FIXME FIXME FIXME

So instead I decided to try something else: our demo engine will always run at native resolution, but it will render in a buffer that has its own separate resolution and which we have full control over. This way we can present the user with only a few resolutions to choose from, we can present them in a clearer way (we went for the 720p/1080p notation that is now common in TV and streaming) and more importantly, we avoid entirely the dreaded resolution switch and its aftermath. There is a bit a care to have when it comes to fitting the demo's intended aspect ratio within the monitor aspect ratio, but you only have to write that code once.

This is how it looks, but you can also see it live in our most recent intro and demo:





Any thoughts on this or improvements to suggest?

P.S.: Also mind the multiple monitor setup, and make sure to check which one the demo is opened on, so the user can hint you one they want to run the demo on.

Well, I pressed the wrong button before finishing to write the post. :-/

FIXME: I wanted to add something about the resolution list not being quite user friendly, as we don't really care what the exact resolution will be. Anyway, that's certainly not the main point.

Ah I forgot to mention another advantage of doing that: on some monitors, certain resolutions will be stretched, while others will be padded with black bars. On my 16/10 monitor for example, switching to 1920x1080 with show a 19/9 render area and black bars.

As far as I'm aware of, there is just no way of knowing when that happens, which means the aspect ratio indicated by the user becomes incorrect, unless they specifically took the black bars into account.

If you always stay with the native resolution, you avoid this additional pitfall.

Enumerate, default to current, allow fullscreen/windowed/borderless, in the latter case open to native, resolution selects backbuffer size, and it's up to the user to select the correct aspect ratio.

By correct I mean "same as the physical screen". The demo should run with your chosen aspect ratio and you should letter/pillarbox accordingly.

I can see 2 reasons to enumerate the supported resolutions:

1. A hypothetical setup that would, for some reason, require a specific resolution (I can't remember this happening to me even once when watching a demo, but beam teams may have a different experience :) ). Then just let the user choose that resolution directly in their OS or setup. The demo has no business in switching the resolution of the system.
   


2. Balance between visual detail and performance. Choosing the size of the render buffer does that, without affecting your other programs. Similarly, some games will offer a super-sampling setting (like 0.8x to 2x for example), or even do it dynamically during gameplay.
   

So my point is we don't need to enumerate at all.



Like I said above, in some cases it's not straightforward, as the aspect ration of the render area provided to the program can be different than the one of the monitor, and whether or not they match depends the way the monitor handles each resolution.
We can decide that it's the user's problem, or we can decide to make a UI that avoid this case and makes their experience a bit better.



Yes, absolutely.

While are talking about the aspect ratio selector... I think rephrasing the UI a bit could also help because to me it's never quite clear why I have to choose it... I think the default assumption to make is that pixel ratios are 1:1 (i.e square pixels), and the aspect ratio should only matter if the monitor stretches non-native resolutions. If we assume that 1:1 pixels are common enough, I think a it would be helpful if the dropdown was labeled monitor aspect ratio (mind the extra word) to make clear why two different values have to be configured. Maybe with an option "don't care, my monitor doesn't stretch pixels" which could be the default and always assume 1:1 pixels.

The window messing seems to be happening on OpenGL mostly?

Yup, I agree.
In the screenshot above you can see we were already using "Monitor aspect", but we've changed for "Display aspect ratio" to encompass projectors. I hope this is clear enough, but if someone has a better suggestion please share it.

If you display everything in native resolution and scale the render buffer, there shouldn't be need for aspect ratio selection. All you need to do is calculate the area where scaled render buffer image is rendered and fill the rest with black. Everyone having square pixels in native resolution is suitable assumption.

Besides adjustable aspect ratio it would be great to offer two options above the resolution list "No aspect ratio scaling" and "Auto aspect ratio scaling". Default to no scaling. Calculate auto aspect ratio scaling from aspect ratio during the launcher startup.

Ive been thinking about multi monitor setups. As happy as I am if some launcher lets me actually choose which screen to run the demo on instead of picking the first it can find (think notch), wouldnt it be cool to have a demo running on multiple screens? They could be used to stretch the resolution or to show something different on each, NDS style.

What about just using a multiplier?

or just don't be a bum and get a proper curved extra wide screen monitor, multi-monitor sucks

I've played games in all sorts of resolutions (some of which definitely use OpenGL) and I don't recall ever having a game mess up icons or windows. What do they do differently?