Cannot adjust scaling/resolution in fullscreen mode v2.5.1

[psoma]

Hi,

I've been running ScummVM 2.2.0 x64 in Windows 10 with a CRT running 640x400 for a lovely, lightly scanlined, integer scaled OpenGL output (or 640x480 for newer games like Gabriel Knight 2). Today, I wanted to play Little Big Adventure so I installed 2.5.1 but no matter what combination of graphic mode, scaler or stretch option I tried, I couldn't adjust the scaling/resolution in fullscreen mode in game or in the UI (it didn't respond to Ctrl + Alt + +/- at all, though it works in windowed mode) - it would always launch and stay in 1024x768, even if the scummvm.ini said the last fullscreen mode was 640 x 400.

Is this a bug?!? I've rolled back to 2.2.0 which responds to the hotkey in fullscreen mode but that limits me to the games that were supported as of its release.

Cheers,

Tom

[rootfather]

We changed how determining the screen size works in OpenGL during the 2.5.0 release cycle. Usually, you don't need to set the resolution on your own, but if you want to restore the "old" behavior, set "Graphics mode" to "SDL Surface".

Please note that it won't change the "real" output resolution, since that's how SDL2 works.

[psoma]

Bummer - yeah, I can see in SDL Surface I can change the "resolution" but to your point, it changes the resolution the game is rendered in, but not the resolution of ScummVM itself.

So was 2.2.0 written in SDL1 and 2.5.1 using SDL2... because using the 2.2.0 release from the web (not the SDL1 build or anything) works as I expect it (ie. screen resolution changes to match the UI and game resolution)?

[rootfather]

It depends which build you were using - to my knowledge, our official 2.2.0 release was already done with SDL2. Maybe you used a build provided by a third party that was still using SDL1?

At this point, there's nothing we can do about it - SDL2 simply does resolution switching completely differend than SDL1 used to do.

[psoma]

Sorry, edited my earlier post to add detail... but I just downloaded a fresh version of the 2.2.0 build off your website again, it's definitely the SDL2 build - it has the SDL2 dlls in the zip, but when I run it, the output resolution definitely changes as expected (using the same INI as 2.5.1).

[rootfather]

Okay, then we need to dig deeper - I can't tell why the behaviour changed from 2.2.0 to 2.5.1 for the SDL Surface renderer as well. The changes using the OpenGL mode can be simply explained by all the auto-detection and scaling features we added, but I can't tell why the SDL Surface renderer behaves this way.

Maybe one of our devs can chime in and give more details

[rootfather]

I found the explaination for the behaviour you've seen: We switched to OpenGL as default renderer in 2.5.0, while Surface SDL was the default renderer in all previous versions. This means that 2.2.0 should behave exactly the same way as 2.5.1 when you set it to OpenGL mode as well.

[psoma]

Hmmmm - this is where the interesting bit kicks in. I just checked and confirmed I *am* running 2.2.0 in OpenGL mode. If I switch it back to "no scaling" (which I assume is the same as Surface SDL) - it *does* behave the same as 2.5.1 does in SurfaceSDL - ie. it always outputs 1024x768 (my native Windows resolution) and just scales the UI/game rendering when using the Ctrl+Alt+(+/-) hotkeys. When I switch back to OpenGL in 2.2.0, the CRT resolution changes to match the reported resolution when I cycle through Ctrl + Alt + (+/-) scalings - this is confirmed by the on-screen-display information of the monitor.

Just to make it explicit too - the Ctrl + Alt + (+/-) hotkeys do absolutely nothing in OpenGL mode in 2.5.1... it's like the auto-detection and scaling cannot be overridden and has broken this ability.

[rootfather]

Just to make it explicit too - the Ctrl + Alt + (+/-) hotkeys do absolutely nothing in OpenGL mode in 2.5.1... it's like the auto-detection and scaling cannot be overridden and has broken this ability.

Yes, this conflicts with the auto-scaling and high-resolution features we added - so you need to use Surface SDL indeed.

[criezy]

I would guess the main reason for that change in behaviour is that we are now using the SDL_WINDOW_FULLSCREEN_DESKTOP for OpenGL instead of SDL_WINDOW_FULLSCREEN. That was changed in April 2021, so between the 2.2.0 and 2.5.0 releases. That flag indicates that fullscreen uses the current desktop resolution and SDL scales the display to that resolution internally.

On the other hand all the other graphics modes (now grouped under Surface SDL) have been using the SDL_WINDOW_FULLSCREEN_DESKTOP flag ever since we switched to SDL 2 (for the 1.9.0 release). So in that respect it should behave the same way in 2.2.0 and 2.5.0.

I am not very familiar with SDL, but if I understand "current desktop resolution" correctly, that would indicate that if you can change your desktop resolution to 640x480 before switching ScummVM to fullscreen, then that is the resolution it should be using in fullscreen.

Some references:
The documentation for SDL_WINDOW_FULLSCREEN and SDL_WINDOW_FULLSCREEN_DESKTOP: https://wiki.libsdl.org/SDL_WindowFlags
Commit that changed the flag for the OpenGL mode: https://github.com/scummvm/scummvm/commit/bb15133a0

[psoma]

Yeah - I get the move. I'm very much a niche case (I built up a modern system with a CRT so I can run everything in native resolutions) whereas the way 2.5.1 works makes things look right "out of the box" for 99.9% of users with modern, high-res displays.

The move to SDL_WINDOW_FULLSCREEN_DESKTOP explains the behaviour too... it therefore isn't a bug, it's expected with that change. And yeah, if I change the resolution prior to launching ScummVM, it carries that through. Knowing this, I'll use 2.2.0 for the games that run 640x400 (as I can't change my Windows desktop to that res) and launch 2.5.1+ in 640x480 compatibility mode which is what the newer games like LBA seem to use anyway.

Thanks guys - appreciate the clarification, and whilst it'd be great if there was a way to select the behaviour, I'm not expecting it for the few like me it will benefit.

Cheers,

Tom

[psoma]

For anyone who stumbles across this looking to do the same... I've found a workable workaround!

Am now using a program called "Display Changer" - https://12noon.com/?page_id=80 which changes the desktop resolution to whatever you specify, then launches a program and changes it back once it has finished running. I've created batch files that run ScummVM 2.5.1 in either 640x400 mode to support all the DOS based games on my CRT or 640x480 mode for the Windows games or those that run in 640x480:

C:\emulators\displaychanger\dccmd.exe -width=640 -height=400 "c:\emulators\scummvm251\scummvm.exe"

or

C:\emulators\displaychanger\dccmd.exe -width=640 -height=480 "c:\emulators\scummvm251\scummvm.exe"

Hope that helps.

Tom