GRAPHICS3D: Use SDL_WINDOW_FULLSCREEN_DESKTOP for fullscreen in 3D games

[somaen]

This is a tiny change, code wise, but it may need a bit of testing/discussion nevertheless, thus pushing as a PR.

On macOS using SDL_WINDOW_FULLSCREEN leads to a fullscreen scenario where CMD-TAB and other ways to switch applications are disabled, which is inconvenient. This mode is also unaware of the notch that was added to the latest series of MacBooks, thus rendering in that part of the screen, and losing the bit that is covered by the notch.

If we instead use SDL_WINDOW_FULLSCREEN_DESKTOP (like we already do for 2D titles), both of these problems go away.

This resolves https://bugs.scummvm.org/ticket/13454

And since the new behaviour is seemingly the same as clicking the green window button (minus being able to see the window border in fullscreen), this also makes https://bugs.scummvm.org/ticket/13453 a non-issue.

[lotharsm]

That's interesting, I remember having a few issues with entering and leaving fullscreen mode on Ubuntu as well regarding 3D games.

So with this change, all 3D games should behave exactly like 2D games, right?

[ccawley2011]

Does this work as expected for Grim Fandango and Escape from Monkey Island on systems without framebuffer support?

[criezy]

I think the change makes sense. As far as I know the main case where using the old SDL_WINDOW_FULLSCREEN is interesting is when using ScummVM on a retro-system with a CRT monitor that natively supports multiple resolutions. But that's an edge case, and for the 2D SDL Surface and OpenGL graphics backend we already switched to using SDL_WINDOW_FULLSCREEN_DESKTOP.

But it might indeed be a good idea to check a game with each 3D engine to make sure they are all working properly with this change.

I am also wondering if the Nintendo Switch hack a few lines above the change is still needed with that change.

[lotharsm]

Any updates on this?

[somaen]

I can't test this on Switch, but I can test on each of the 3D engines at least.

[somaen]

Hmm interesting, a quick test with Grim Demo revealed a thing I hadn't spotted earlier:

I can alt-enter back and forth perfectly fine, and I can press the green button to go fullscreen and back, HOWEVER, if I enter fullscreen with the green button, then alt-enter will rescale the viewport to be 640x480-ish in the lower left corner, but remain fullscreen.

And:

If I enter fullscreen with alt-enter, then I won't have the green-button available to exit, the only way to exit (except switching spaces), is to alt-enter back out.

On top of this there's a single frame drawn stretching the game across the entire screen (ignoring aspect), before it pops back to the right aspect.

Comparably, the old behaviour:
alt-enter will go straight to full-screen without the above-mentioned aspect issues, however this kind of fullscreen is not notch-aware, and does not support switching spaces, effectively locking the user into the fullscreen.

green-button fullscreen will yield the same result as above, including the aspect issues, however if you press alt-enter in this state, ScummVM will segfault:

2022-10-16 22:59:49.742 scummvm[65670:6015059] NSWindowStyleMaskFullScreen cleared on a window outside of a full screen transition. Called from (
0 AppKit 0x00000001956d8b08 __25-[NSWindow setStyleMask:]_block_invoke + 156
1 AppKit 0x00000001956d8a10 NSPerformVisuallyAtomicChange + 140
2 AppKit 0x00000001956d8910 -[NSWindow setStyleMask:] + 200
3 libSDL2-2.0.0.dylib 0x0000000106e27a58 Cocoa_SetWindowFullscreen + 444
4 libSDL2-2.0.0.dylib 0x0000000106e0b9b0 SDL_UpdateFullscreenMode + 740
5 libSDL2-2.0.0.dylib 0x0000000106e0d064 SDL_SetWindowFullscreen_REAL + 176
6 scummvm 0x0000000104bffd58 _ZN9SdlWindow20createOrUpdateWindowEiij + 580
7 scummvm 0x00000001050bbcac _ZN26OpenGLSdlGraphics3dManager23createOrUpdateGLContextEjjjjbb + 844
8 scummvm 0x00000001050bae00 _ZN26OpenGLSdlGraphics3dManager20createOrUpdateScreenEv + 312
9 scummvm 0x00000001050bac98 _ZN26OpenGLSdlGraphics3dManager15setFeatureStateEN7OSystem7FeatureEb + 140
10 scummvm 0x00000001050a4574 _ZN18SdlGraphicsManager16toggleFullScreenEv + 304
11 scummvm 0x00000001050a43e4 _ZN18SdlGraphicsManager11notifyEventERKN6Common5EventE + 208
12 scummvm 0x00000001056eb3f4 _ZN6Common15EventDispatcher13dispatchEventERKNS_5EventE + 108
13 scummvm 0x00000001056eb1c4 _ZN6Common15EventDispatcher8dispatchEv + 620
14 scummvm 0x0000000105038f1c _ZN19DefaultEventManager9pollEventERN6Common5EventE + 80
15 scummvm 0x0000000104cbb364 _ZN4Grim10GrimEngine8mainLoopEv + 736
16 scummvm 0x0000000104cbace8 _ZN4Grim10GrimEngine3runEv + 2660
17 scummvm 0x0000000104c07098 _ZL7runGamePK6PluginS1_R7OSystemRKN6Common6StringE + 3160
18 scummvm 0x0000000104c05650 scummvm_main + 3252
19 scummvm 0x0000000104c019e0 main + 204
20 dyld 0x0000000106b65088 start + 516

So overall I think this may require a bit more research, and/or discussion before we settle on a choice, the lack of notch-awareness is suboptimal on the new MacBooks, but the transition is suboptimal currently, and the notch-aware behaviour is available through the green-button.

[elasota]

This should be a good change on Windows as well, recent Windows versions have changed fullscreen behavior in a way that there isn't really any advantage to using exclusive fullscreen any more.

[lephilousophe]

On Linux, I don't see any difference between SDL_WINDOW_FULLSCREEN_DESKTOP and SDL_WINDOW_FULLSCREEN.
By looking at SDL code, it seems that fullscreen always means a maximized window without any border.
There is no concept anymore of exclusive fullscreen.

EDIT:
The old way is removed since SDL 2.24.0 and has only been used as a fallback mechanism since SDL 2.0.

[sev-]

I wonder, what is the behaviour in 2024?

[lephilousophe]

PR #6651 will make this PR irrelevant.
SDL_WINDOW_FULLSCREEN_DESKTOP will be used on SDL2+.

[bluegr]

PR #6651 has been merged now, so this can be closed