[SDL1/2]: Fullscreen squeezed while Window is fine

[raziel-]

Hard to explain, easier to show (see screenshots)

I have an engines in ScummVM that seem to open it´s screenmodes incorrectly in fullsreen mode. (The engine is called wintermute and it happens with every renderer mode.) Probably because of the black bars on top and bottom (not sure where they come from).

Fortunately there is a freely available game (Bickadoodle) for easy testing. Get the game here: https://aethericgames.itch.io/bickadoodle install it, add it to the launcher and run it.

In fullscreen it looks like in pictures 1 and 2, switching in the same exact session to window, the game is crisp and sharp and i can even read what is written there.

I have opened a question on the ScummVM forums as well, but i doubt it´s an engine problem since there never was a similar complaint ever. (Though i remember those black bars gave problems in the past on other engines, but that always was a platform driver problem in the end).

[raziel-]

The game seems to play natively in a 1024x768 resolution, but is, for some reason, squeezed into a 640x480 resolution, inlcuding adding hose black bars. I don't know why, since i have a perfectly working 1024x768 resolution ready in screenmode prefs, but it's not getting picked up.

[capehill]

This doesn't seem AmigaOS issue. I'm running the latest ScummVM on Linux Mint here and when starting with OpenGL renderer, I have the black borders top & bottom. Fullscreen (via Alt-Enter) doesn't seem to help.

With normal renderer, window mode still has borders but now fullscreen looks a little bit better.

Finally, starting with normal renderer with fullscreen, and the Alt-Entering to window mode, makes game window really small.

My conclusion is that this game engine doesn't work 100% on Linux either.

[raziel-]

Haven't gotten answer to this question either yet, but i added your comment to the forum thread. With luck some Linux users will join in

[raziel-]

This is a strange one.

It seems this issue is also present in non-OpenGL mode, albeit rather randomly. i.e. if i start Bickadoodle in fullscreen (non-OpenGL) it will be squeezed. If i switch to window mode and back it will be drawn just fine.

This workaround will not work with OpenGL, though

[raziel-]

I think i get it now.

To get a crisp game screen in OpenGL mode i need to set the OpenGL screenmopde in ScummVM to either my monitors "suggested" resolution (2560x1440 - it's maximum size) or seomthing that is a divisable factor of that (e.g. 1280x720, 640x360 etc. - still need to test the inbeetween modes) . If i choose some other screenmode (which has to be set manually in scummm.ini or by clicking through the available screenmode with CTRL+/- -i think, it was- while in launcher) i always get dissorted output. . The same happens (to an extent) in non-OpenGL AND in OGLES2, so i guess it might be a gfx driver problem?

I guess this can be closed then?

[capehill]

I guess you can always try to simulate problem with some appropriate style/sized font on "bad" screen modes, but I think it's more of an engine issue than driver.

[raziel-]

I did some more testing with fullscreen and window and cycling thorugh the available modes with ScummVM's LCTRL+LALT+"+ or -".

In window mode i can get those resolutions to show up while cycling through them: 320x240 (not in Screenmode Prefs) 640x480 960x720 (not in Screenmode Prefs) 1280x960 (not in Screenmode Prefs) 1600x1200 (not in Screenmode Prefs) and differnt sizes of 2540x1410 which is probably because the window will only draw up to the WB screen borders and due to it's own borders lose some of the max size of 2560x1440 (which is the max resolution i can get)

In fullscreen i can get those while cycling through them: 640x480 720x400 800x600 832x624 1024x768 1152x870 1280x800 1280x1024 1600x900 1680x1050 1920x1080 2560x1440 These are all screenmodes i have set up in screenmode prefs (according to my monitor's manual) except 1280x720. (Whcih doesn't seem to be picked up for some reason).

The window modes are not reduced to the above list though, as it can adapt (probably) any resolution it is asked for. e.g. if i set up a scummvm window in 640x480 and start "Chivalry is not dead" (a game that asks for a 800x600 resolution [and is free to play, see link below], the window will perfectly switch to the asked resolution, resizing itself and displaying the game crisp and sharp.

The fullscreen mode however does nothing of the above. If i start the game from a launcher resolution of 640x480, it will be cramped into that very resolution and will look squeezed, have hard to read fonts and overall look ugly. IF i however start the game from a launcher reslution of 800x600, it will also be crisp and sharp

The problem i see is that fullscreen does not (opposite to the window mode) respect and/or change the resolution to what the game asks, which leads to the mentioned graphics issues.

Chivalry is not dead (This game is a great test case because it opens a text window on start which makes checking the sharpness easy. You need a scummvm version with wme engine built in, just like with Bickadoodle) http://games.squinky.me/downloads/chivalry/chivalry.zip

[raziel-]

@capehill

I'll gladly add more test cases, if needed?

[capehill]

I will test Chivalry on Linux.

[capehill]

Tested Chivalry on a Linux laptop, using the latest ScummVM source, in 640*480 OpenGL fullscreen mode, and text becomes difficult to read. I think you need to discuss about issue with ScummVM devs who know the engine better than me.

[raziel-]

Will do. Thank you for the test.

[capehill]

@raziel- Any good news here?

[raziel-]

I'm afraid no news at all.

I relayed the information and your test to the scummvm bug tracker (https://bugs.scummvm.org/ticket/11160), but unfortunately the dev that was working heavily on the Wintermute engine and bugs went silent for some months now...

Have to wait until (if ever) he pops up again.

[capehill]

@raziel- Can I close this one as an ScummVM issue instead of AmigaOS4 SDL?

[raziel-]

I guess so, yes.

[capehill]

Thanks, let's hope the engine developer returns.