Fullscreen "switch resolution" option not working

[Q3BFG10K]

I have a 2560x1440 display and use nVidia 4xDSR (5120x2880). Win7-64, OpenGL 3.2.

Yamagi doesn't switch to that resolution and instead fills the screen with an incorrectly stretched bottom-left quarter. Fan-patch Quake 2 (3.24) works fine and correctly sets 5120x2880x144Hz.

I can get Yamagi to work correctly if I switch my desktop to 5120x2880 BEFORE launching it, which shouldn't be necessary.

Thank you.

[Yamagi]

That's likely another problem with SDLs fullscreen switch and not Quake II. When "switch resolution" is selected, we're just telling SDL that it should switch to the requested resolution when entering fullscreen and not stick to the current resolution. If the switch fails - likely because the requested resolution is not listed as supported by Windows or the GL driver - SDL falls back to the standard approach and positions the window at the lower left of a black area. There's nothing we can do about it.

[Q3BFG10K]

DSR resolutions are fully supported by the driver, and fully integrate into Windows. You can select them in the control panel slider just like any other resolution.

I have many OpenGL source-ports that also use SDL (e.g. Quakespasm, Marathon Aleph One, Doomsday engine, Hammer of Thyrion), and they all correctly set the resolution.

There’s no black area. Yamagi seems to be running some kind of borderless windowed mode. So it internally sets itself to 5K, but only displays one quarter of that because the display is still set to 2.5K. That’s why setting the desktop to 5K before launching the program fixes it.

I’ve seen this with other borderless window games (e.g. a Unity engine) so ordinarily I wouldn’t report this, but I reported it because there’s a specific “switch resolution” setting in Yamagi which isn’t working.

[Yamagi]

I had a deeper look and there's definitely something wrong. I don't know on our side or with SDL2. I'll do a deeper analyzes after the next release (to be out in the next few days) and after we've finally removed SDL 1.2 support.

[Yamagi]

I believe that this is fixed in my sdlremoval branch. For me the fullscreen resolution fix is now working on Windows 10 (tested with my Radeon R7 360), on Linux (tested with Kaby Lake GT2) and on FreeBSD (tested with a Geforce 750TI).

[Q3BFG10K]

Great, I look forward to testing it when it's merged into the main branch. Cheers.

[vernzimm]

I can second this behavior on Win10 and nVidia running v7.30. Any chance you can compile Win executable for us so we can let you know if it is working? I am not a dev. and it would take me all afternoon to actually compile it myself. Sad but true :/

[Yamagi]

The changes are in our latest release 7.30.

On Sun, 16 Sep 2018 10:28:12 -0700 vernzimm notifications@github.com wrote:

I can second this behavior on Win10 and nVidia running v7.30. Any chance you can compile Win executable for us so we can let you know if it is working? I am not a dev. and it would take me all afternoon to actually compile it myself. Sad but true :/

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/yquake2/yquake2/issues/302#issuecomment-421800203

-- Homepage: https://www.yamagi.org Github: https://github.com/yamagi GPG: 0xeb1472e71d502515

[vernzimm]

Ah, ok, I got it now. I didn't know there were other options for fullscreen. I was using keep resolution, but instead should use change resolution. That works as expected, thanks 🍺

[Yamagi]

Looks like it's finally fixed. :)

[77Mynameislol77]

Hello, sorry to bump this, but i'm playing with a CRT capable of resolutions between 640x480@200hz to 1600x1200@110hz, but since windows does not think it is capable of that resolution, i have to use the Nvidia Control Panel to create a custom resolution of 640x480@200hz.

The problem is, that when i set my resolution to that ingame, and use the console to set the refresh rate to 200, it instead upscales 640x480 to 1600x1200@110hz instead!

I've tried other sourceports, and on all of them the resolution works fine, but has other issues.

[Yamagi]

Generally YQ2 itself hasn't much to do with the resolution selection, fullscreen switch, etc. We're just telling SDL - https://libsdl.org/ - what we want / the user requested and the library does the rest. If things go wrong the problem is likely on SDLs side... Nevertheless:

that when i set my resolution to that ingame

How do you set the resolution? If through the menu, is fullscreen set to keep resolution or switch resolution? If through the console, what cvars do you use?

and use the console to set the refresh rate to 200

That shouldn't be necessary. The vid_displayrefreshrate doesn't set the displays refresh rate, it tells YQ2s timing code what the displays refresh rate is. Normally that's auto detected, the CVar is just for cases were the autodetection doesn't work.

[77Mynameislol77]

It's set to "Switch Resolution", i've not set it through the console.

It works fine if i switch the resolution to 640x480@200hz beforehand, but i feel like that shouldn't be necessary.

Is there no way to force the resolution you choose? If it is libsdl that is the problem it's strange that the issue isn't happening in any other source ports

[Yamagi]

Hmm... After some pondering I think that SDL switches to wrong mode, maybe it gets confused by fake resolutions. @DanielGibson have you any experience with fake modes and SDL under Windows?

[Yamagi]

Okay, I've added some code to YQ2 that prints the available display modes and what mode was choosen. Can you test it with this binaries: https://deponie.yamagi.org/quake2/misc/quake2-20190625-459746c.zip After that, send us the C:\Users\$USERNAME\Documents\YamagiQ2\stdout.txt It contains the full console output. Thank you!

[77Mynameislol77]

stdout.txt

[Yamagi]

Thank you! Now I'm seeing the problem. You're requesting (at least from YQ2s perspective) 512x386. While there's a mode 512x384@200 you're getting 512x384@110. Looks like we're missing a call to SDL_SetWindowDisplayMode() somewhere. I'll see if I can come up with a patch in the next few days.

[77Mynameislol77]

awesome, thank you!

[Q3BFG10K]

FYI, this issue was never resolved for me.

Setting 5120x2880 in-game menu still gives me 2560x1440 with only one quarter of the screen showing unless I switch the desktop to 5120x2880 before launch. Forcing r_customwidth/r_customheight doesn't work either.

From the attached file it's using mode 31 which is a nonsensical 2560x1440@23. Trying r_mode 0 (which is listed as 5120x2880@144 in the file) from the console gives me 320x240.

There appears to be a serious mismatch between the actual modes and what the game tries to use. No other OpenGL/SDL sourceport I've used has this issue, only Yamagi.

stdout.txt

[Yamagi]

The values passed to r_mode have nothing to do with the SDL modes, listed by my code. That's just the non-architecture of Quake II... The way is:

• The user passes r_mode, either by console or trough the menu. If it's set to -2 the window width and height are taken from the current video mode. If set to -1 the values are read from r_customwidth and r_customheight. If set to 0 or higher the values are taken from a lookup table, for example r_mode 0 is 320x240
• We're passing the width and height to SDL and request a windows with that size from SDL. If vid_fullscreen is set to 1 we'e passing the SDL_WINDOW_FULLSCREEN_DESKTOP to SDL which tells it to keep the current resolution and place the fullscreen window somewhere inside it. If it's set 2 we're passing SDL_WINDOW_FULLSCREEN which tells SDL to switch into that resolution.

The problem that @77Mynameislol77 is seeing is just, that he has several video modes providing a resolution of 512x384. SDL chooses the wrong one. I'll likely work around that by introducing a new CVar that forces a refresh rate.

Your problem looks different. Quake2 is requesting 5120x2880 and SDL switches to 2560x1440. Which exactly the half. At a first look that's some interaction problem between SDL and Nvidias driver, but I'll need to dig into that.

[DanielGibson]

@Q3BFG10K thanks for reporting, this is an SDL bug, I reported it at https://bugzilla.libsdl.org/show_bug.cgi?id=4700

(However I wonder, why you are running your desktop at a lower resolution than the game?)

[Yamagi]

@77Mynameislol77: As promised I've added some code to YQ2 to force a display refresh rate. A new set of binaries can be found at https://deponie.yamagi.org/quake2/misc/quake2-20190702-890d708.zip Set the CVar vid_rate to the desired refresh rate and execute a vid_restart. Please note that we may not switch to the exact refresh rate, but to a close mode. For example setting vid_rate 65 on an 60hz display will switch to 60hz because 65hz is unsupported.

[Yamagi]

@Q3BFG10K: I've tried to hack around the SDL bug, but no chance. We'll have to wait for an upstream fix.

[DanielGibson]

@Q3BFG10K: I'm really curious why you're running the game at a higher resolution than your desktop. So far no one at SDL has reacted to my bugreport (I don't know why, but maybe they, like me, assume that this kind of setup is super rare/obscure), it might help if I can tell them why this is relevant :)

[77Mynameislol77]

It works PERFECTLY. I cannot thank you enough.

[DanielGibson]

@Q3BFG10K: I'm really curious why you're running the game at a higher resolution than your desktop. So far no one at SDL has reacted to my bugreport (I don't know why, but maybe they, like me, assume that this kind of setup is super rare/obscure), it might help if I can tell them why this is relevant :)

ah, I only just noticed that this bug originally started last year and you explained back then what it's for (nvidia DSR) - I'll pass this on to SDL.

[Q3BFG10K]

@DanielGibson, @Yamagi, thanks for your help.

Yes, I use 5K DSR to run resolutions higher than my native 2560x1440. It works fine in other OpenGL sourceports that use SDL like GZDoom, Marathon Aleph One, Quakespasm, and Hammer of Thyrion. They all correctly switch to the higher resolution.

[Yamagi]

@77Mynameislol77: Thank you for the feedback. The fix is now in master, it'll be part of the next release.

[Yamagi]

@Q3BFG10K: I might have found a work around to your part of this issue. Can you give the build under https://deponie.yamagi.org/quake2/misc/quake2-20190705-6db1203.zip a try?

[Q3BFG10K]

@Yamagi, that fixed it!

Thanks heaps.

[Yamagi]

The changes and some follow-up fixes are now in master, they'll be part of the next release. I'm closing here but feel free to reopen for the next round. ;)