Resolution Questions

[Mike12]

While the dPjudas response clarified some things, the thread was closed early and I still have questions about the status of the resolution screen.


Will the resolution selection screen (be it in the future vid_mode reinstatement, or by functioning with whole new code/scaling selected pixel resolution to the current monitor res) still be intact in window and full screen modes? Because as a developer I rely on those a lot for all sorts of graphic development. I kinda got this impression from dpJudas's statement, but i'm hoping to figure things out crystal clear.

I think I understand the issue with exclusive fullscreen and so long as everything is responsive i'm not super bothered by borderless windows, I'm just hoping that I'll still be able to select my resolutions (at least from a visual standpoint, even if it's technically still the monitor res in code).

[dpJudas]

There is no change to the input response in full screen - it will be exactly like in GZDoom today. When Windows sees a window that covers the entire screen it turns off the DWM, making the application render directly to the screen with no extra latency.

[Mike12]

There is no change to the input response in full screen - it will be exactly like in GZDoom today. When Windows sees a window that covers the entire screen it turns off the DWM, making the application render directly to the screen with no extra latency.

I think I understand. My only other question is about the resolution selection screen - will I still be able to use that or a very similar screen to select set "resolutions" even if the code/method/etc for it is entirely different (based on scaling instead of screen resolution)? I apologize if this was already addressed and I missed it somehow, I'm just making sure I have the full picture before i return to work.

[Rachael]

There are vid_scaletowidth and vid_scaletoheight commands.

I am not sure if they suit your needs, but what they do is effectively set vid_scalefactor based on GZDoom's current window/screen geometry.

Example: vid_scaletowidth 800 sets vid_scalefactor so that the scaling is 800 by X, where X is however tall the screen is, if your screen was 800 wide.

Does that answer your question, sufficiently?

[Mike12]

There are vid_scaletowidth and vid_scaletoheight commands.

I am not sure if they suit your needs, but what they do is effectively set vid_scalefactor based on GZDoom's current window/screen geometry.

Example: vid_scaletowidth 800 sets vid_scalefactor so that the scaling is 800 by X, where X is however tall the screen is, if your screen was 800 wide.

Does that answer your question, sufficiently?

Ah, ti's more that I'm hoping for (>attachment) for quick adjustment of what scale it renders in fullscreen or windowed, except that it uses whatever the new method is instead of actually changing monitor resolution - that way I can still change it to scale to basic resolutions on the fly and save command use for anything more abstract - I'm hoping I won't have to use commands to change to the basic "resolutions" and can still have the ease of use the screen provides even if the functionality is different.

[dpJudas]

The answer to that question is a maybe, Mike12. At the moment you can select some of those sizes in the menu already (320x200, 640x480, 800x600, not sure which else). Adding more to that list is trivial if someone feels we left out some important resolution.

Given how much space we gained from removing the old video list, maybe we could show it in a form better than as single line multiple choice as it is now. However, we need an UI way of presenting this that makes it clear to a user that he doesn't have to pick any of the items on such a list. Not to mention someone volunteering to implement it - and Graf signing off on the idea, of course.

[Mike12]

Alright, I think I see! That should do it, thanks.

[Rachael]

I did a thing.

Well, the backend part is done. Just need someone to present a UI way of doing this. I honest to god have no idea the best way to present a UI for this option.

(I managed to do this with only one pair of hacks! )

[leileilol]

Since this silly "modern; you don't need that" regression is reportedly inspired by Blizzard games of a completely different genre, maybe you can model it after their actual first-person shooter game which does offer a drop-down list of video modes sorted by refresh rate, with an aspect option to filter the list?

[RiboNucleic Asshat]

Pardon me if this is a dumb question, but can't it just be set up so that the UI looks exactly the same with the way it works in the back being different?

[Xaser]

This seems like a great time to improve the UI on that screen, rather than replicate it. That big ol' grid of resolutions was always rather unsightly and difficult to pick through, IMO.

[Graf Zahl]

Since this silly "modern; you don't need that" regression is reportedly inspired by Blizzard games of a completely different genre, maybe you can model it after their actual first-person shooter game which does offer a drop-down list of video modes sorted by refresh rate, with an aspect option to filter the list?

No. For the simple reason that there is no mode change anymore. So you cannot change refresh rates. All you can do is change the scaling to get the number of scaled pixels to the desktop sized screen.
I have said it multiple times now: The reason for this change was to get rid of the display mode change, which was a source of some serious problems and which was messing up the entire video backend code.

If this was Direct3D we could do an exclusive mode change, but since OpenGL always renders to the desktop, this cannot be done robustly! You have to change the desktop resolution and this is something Windows really does not like (and it would not surprise me if this feature eventually gets removed in the future.)

This seems like a great time to improve the UI on that screen, rather than replicate it. That big ol' grid of resolutions was always rather unsightly and difficult to pick through, IMO.

Agreed on this one. The menu also had its share of major issues, for example it had to use a rather large amount of backing code to do its job.

I did a thing.

Well, the backend part is done. Just need someone to present a UI way of doing this. I honest to god have no idea the best way to present a UI for this option.

(I managed to do this with only one pair of hacks! )

I'm not really sure this is a good start to build upon. I mean, having a custom option in there is certainly not bad, but wouldn't it be better to have the most common resolutions explicitly listed?

[Nash]

As I've suggested before - a single line widget, press left and right to scroll through various dimension presets, press Enter to execute it. :)

Code: Select all

Window size				< 1920x1080 >
							   'Enter' to confirm

Another solution would be a combo list widget, like in typical Windows-style GUIs.

[PlayerLin]

If this was Direct3D we could do an exclusive mode change, but since OpenGL always renders to the desktop, this cannot be done robustly! You have to change the desktop resolution and this is something Windows really does not like (and it would not surprise me if this feature eventually gets removed in the future.)

But DooM 2016 is OpenGL too(before Vulkan renderer happens), or idtech5 just do hacky way too since Windows doesn't like that?

[Graf Zahl]

Does it actually physically change the resolution? I cannot say because I do not own the game. But be it as it may, being able to do this stuff is merely still there because Windows itself needs to do it and for compatibility with old stuff. The OS doesn't play nicely with it at all.

If you overdepend on obsolete features, something will bite you sooner or later - that's how things work. Much of what was removed now is nearly 20 years old - made for a completely different class of displays and operating systems. In case you haven't noticed: SDL2 (i.e. Linux) and macOS no longer support live display mode switching AT ALL! Don't expect this to remain in Windows for all eternity. It makes little sense with today's displays and can safely be considered a legacy feature squarely aimed at providing backwards compatibility with old software.

And that clearly shows in how it behaves on modern Windows versions (which is, like shit.)