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...

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_...

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...

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).

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 S...

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 graph...