GRAPHICS: OPENGL(3D): Switching screen modes erases game graphics, or may crash app.

[macca8]

When playing a game that uses 3D OpenGL (in my case, Myst3), pressing Alt+Enter erases the game graphics when the screen mode changes. Further switches fail to restore the graphics, requiring the user to exit the game, either by returning to the Launcher or quitting.

Fortunately, the user can save their progress before exiting by accessing ScummVM’s Save dialog. Not surprisingly, this save features a blank thumbnail image, but is fully functional when reloaded after shutting down the game engine.

Note that only the game’s graphics are erased, any sound continues as normal, and the GMM remains accessible (see attached screenshot).

Switches in 2D games, or the Launcher, that use standard OpenGL or other graphics modes are not affected by this issue.

This first appeared in daily build 2.3.0git15408-g9818b47554 (Apr 18 2021), and is likely a regression from ​https://github.com/scummvm/scummvm/commit/d33487f641bcd6e9e4d31a0bf91f7abf2f92c2e0 - SDL: Refactor OpenGLSdlGraphics3dManager to inherit from SdlGraphicsManager - which was committed in that build.

Tested on an Intel Mac running macOS 10.11.6, with a LoDPI screen (max 1920x1080).

Truth be known, this is likely the same bug as reported in #12473, however since I’m seeing a totally blank (white) screen, these observations may contribute to a more complete overview of the issue.

Edit: See also comments 5 & 6 below for a variation of this behaviour applicable to using OpenGL with shaders (with Myst3).

[criezy]

Thank you. But this is indeed almost certainly a duplicate of bug #12473 (it also mentions leaving the screen completely white with OpenGL renderer). So I would be tempted to close this ticket and track the issue in #12473.

[macca8]

Sorry about that. I got confused by the image attached to the other report that depicted an object on the screen, but I guess that was just a test case to highlight another image overlaying the screen (similar to viewing a GUI object in a game).

Feel free to close this ticket if you wish. The important thing is that the issue gets fixed.

[criezy]

OK. I am closing this one as a duplicate of bug #12473 so that all the information is tracked in one place (I have also copied some of the information from this ticket to the other ticket).

[macca8]

Even though this has been flagged as a duplicate of #12473, I'm getting a different response when the 3D Renderer is set to "OpenGL with shaders", so I'm updating this ticket in case it needs to be reopened.

With #12473, using "OpenGL with shaders" on Linux apparently produces a blank black screen when switching between fullscreen and windowed mode.
On macOS, setting the 3D Renderer to "OpenGL with shaders", then switching screen modes in-game, results in an immediate crash with a segmentation fault. This crash doesn't occur with daily builds prior to 18 April 2021.

With regard to using normal 3D OpenGL, attached is a screenshot of the Myst3 game screen with the "widescreen mod" engine option disabled, after switching between screen modes. In this case, the screen's black borders are preserved, but the main screen and inventory items are blank.
With "widescreen mod" enabled, there's no black borders and inventory items are hidden by default, so the result when switching is a completely white screen.

[macca8]

I'm reopening this ticket because the difference between #12473 and this report is now the default behaviour, following a change in the 3D Renderer's default setting to OpenGL with shaders ​(commit a16bc2a).

The specific Alt+Enter bug in Myst3 hasn't changed:

• Pressing Alt+Enter with the 3D Renderer set to default or OpenGL with shaders will crash the app with a segmentation fault.
• Pressing Alt+Enter with the 3D Renderer set to OpenGL will erase the game graphics, but not crash the app.

Aside from this bug, both OpenGL & OpenGL with shaders work perfectly with Myst3 on macOS.

Note that while the crash reports for the 32-bit & 64-bit stable builds (2.3.0pre133) feature the same issue, the 32-bit build adds a couple of extra lines to the trace that aren't included in the 64-bit build's report.

See also #12630 & #12858 for similar Alt+Enter issues affecting other 3D games.