MYST3: Mouse movements are limited to rectangle in full screen mode when using SDL v2.0.18

[eriktorbjorn]

Bisecting points to this commit which, based on its description, makes sense:

c6836c9b7778024617ed4838f7a0bdeaff412cb4 is the first bad commit
commit c6836c9b7778024617ed4838f7a0bdeaff412cb4
Author: Cameron Cawley <ccawley2011@gmail.com>
Date:   Thu Nov 11 19:21:49 2021 +0000

    SDL: Use SDL_SetWindowMouseRect to confine the mouse area

 backends/graphics/sdl/sdl-graphics.cpp |  4 ++++
 backends/graphics/sdl/sdl-graphics.h   |  2 ++
 backends/graphics/windowed.h           |  8 ++++++++
 backends/platform/sdl/sdl-window.cpp   | 20 ++++++++++++++++++++
 backends/platform/sdl/sdl-window.h     |  6 ++++++
 5 files changed, 40 insertions(+)

[eriktorbjorn]

It seems to apply to any game that uses OpenGL rather than software rendering?

[ctoroman]

Yes, it looks like that.

[kalkie]

Does this issue occur in scaled HiDPI mode, e.g. on MacOS with a Retina display? If so, then I've submitted a PR for fixing this issue:
​​https://github.com/scummvm/scummvm/pull/3699

The usage of SDL_SetWindowMouseRect() didn't take the HiDPI scaling into account. Thus, the coordinates of the allowed mouse area were off by the scaling factor, e.g. 2x greater than they should be. Now that this SDL_SetWindowMouseRect() is used, there are actually two parallel mechanisms for grabbing the mouse and limiting its movement to the game's viewport. Because of this, not taking the HiDPI scaling into account limits the mouse movement incorrectly only on the left/top part of the screen.

This issue only happens with the OpenGL graphics mode, because the SDL Surface mode doesn't support HiDPI mode. There are quite a few workarounds for the issue, in addition to changing the graphics mode. One could disable mouse capture (Ctrl+m) or change to one of the stretch modes filling the entire screen with the game. If the game's viewport fills the whole window, the top/left coordinates of the allowed mouse area are zero, and thus not being affected by the incorrect scaling.

[ctoroman]

not fixed...

[ctoroman]

UPD: Pressing ctrl+m helped.

[kalkie]

ctoroman, did you record that screencast with the latest daily build from the master branch? Did the behavior change in any way compared to earlier? If you run ScummVM with debug level 3 or greater, --debuglevel=3, and start the game, what resolution and scaling does it log? Lines looking something like this:
Setting 2560 x 1600 -> 1280 x 800 -- 2

The issue looks somewhat different to what was fixed in PR 3699. There the problem was caused by not taking HiDPI scaling factor into account when setting the mouse area. In practice, this prevented the mouse movement on the left/top edges of the game area. On the right/bottom side, the mouse could move correctly. There also had to be black bars around the game area for the issue to show up.

[eriktorbjorn]

For me, it works correctly if I start the game in fullscreen. Then the debug message says Setting 1920 x 1080 -> 1536 x 864 -- 1.25

But if I start the game in windowed mode and then switch to fullscreen, the mouse is trapped in a smaller area. In that case, the debug message is Setting 640 x 480 -> 512 x 384 -- 1.25

[ctoroman]

kalkie, latest daily build from the master branch has SDL version 2.0.14

I have built my own ScummVM with SDL version 2.0.18 or 2.0.20. That's where the problem comes in. I wrote about it in the title. On older versions of SDL everything works fine.

[kalkie]

eriktorbjorn, Could it be that SdlWindow::setMouseRect() is not be called correctly when switching between windowed and fullscreen modes? I assume you still get a new Setting ... log entry with the higher resolution when you switch to fullscreen, right? I cannot replicate this on MacOS; the allowed mouse area is correctly adjusted when the window dimensions change.

ctoroman, The MacOS daily builds have SDL 2.0.20, and I wasn't aware this isn't the case on all platforms. If this problem has something to do with SDL_SetWindowMouseRect(), which was introduced in SDL 2.0.18, it's clear the build has to be done against new enough SDL.

[eriktorbjorn]

I assume you still get a new Setting ... log entry with the higher resolution when you switch to fullscreen, right?

No, I only get the one "Setting ..." message when the game starts. Switching between windowed and fullscreen mode produce no further debug messages.

Oddly enough, if I start the game in windowed mode I get a 640x480 window (which is sensible), but if I start in fullscreen mode and switch to windowed mode I get a 320x200 window. I have no memory of that happening before, but I almost never run ScummVM in fullscreen mode.

Debuglevel (from command line): 3
Using SDL Video Driver "x11"
Using SDL Audio Driver "pulseaudio"
Output sample rate: 44100 Hz
Output buffer size: 512 samples
WARNING: SDL mixer output buffer size: 512 differs from desired: 1024!
Setting 1280 x 800 -> 1024 x 640 -- 1.25
GUI: Loaded icon file: gui-icons-20211112.dat
GUI: Loaded icon file: gui-icons.dat
HardwareInput with ID 'JOY_START' not known
HardwareInput with ID 'JOY_LEFT_STICK_Y-' not known
HardwareInput with ID 'JOY_LEFT_STICK_Y+' not known
HardwareInput with ID 'JOY_LEFT_STICK_X-' not known
HardwareInput with ID 'JOY_LEFT_STICK_X+' not known
HardwareInput with ID 'JOY_RIGHT_SHOULDER' not known
User picked target 'myst3-win' (engine ID 'myst3', game ID 'myst3')...
   Looking for a plugin supporting this target... Myst III
Running Myst III Exile (DVD/Windows/English)
ENGLISH.m3u: e200b416f43e70fee76148a80d195d5c, 2420378 bytes.
RSRC.m3r: a2c8ed69800f60bf5667e5c76a88e481, 1223862 bytes.
ENGLISH.m3t: 74726de866c0594d3f2a05ff754c973d, 3407120 bytes.
HardwareInput with ID 'JOY_A' not known
HardwareInput with ID 'JOY_B' not known
HardwareInput with ID 'JOY_LEFT_SHOULDER' not known
HardwareInput with ID 'JOY_Y' not known
HardwareInput with ID 'JOY_X' not known
HardwareInput with ID 'JOY_UP' not known
HardwareInput with ID 'JOY_DOWN' not known
HardwareInput with ID 'JOY_LEFT' not known
HardwareInput with ID 'JOY_RIGHT' not known
switching to OpenGL 3D graphics
INFO: OpenGL Vendor: AMD
INFO: OpenGL Renderer: AMD BONAIRE (DRM 2.50.0, 5.16.0-1-amd64, LLVM 13.0.1)
INFO: OpenGL Version: 4.5 (Compatibility Profile) Mesa 21.3.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
INFO: GLSL version: 4.50
INFO: OpenGL Vendor: AMD
INFO: OpenGL Renderer: AMD BONAIRE (DRM 2.50.0, 5.16.0-1-amd64, LLVM 13.0.1)
INFO: OpenGL Version: 4.5 (Compatibility Profile) Mesa 21.3.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
INFO: GLSL version: 4.50
INFO: OpenGL Vendor: AMD
INFO: OpenGL Renderer: AMD BONAIRE (DRM 2.50.0, 5.16.0-1-amd64, LLVM 13.0.1)
INFO: OpenGL Version: 4.5 (Compatibility Profile) Mesa 21.3.5
INFO: OpenGL Red bits: 8
INFO: OpenGL Green bits: 8
INFO: OpenGL Blue bits: 8
INFO: OpenGL Alpha bits: 8
INFO: OpenGL Z buffer depth bits: 24
INFO: OpenGL Double Buffer: 1
INFO: OpenGL Stencil buffer bits: 8
INFO: GLSL version: 4.50
Initializing OpenGL Renderer with shaders
Setting 640 x 480 -> 512 x 384 -- 1.25

[kas1e]

@All
I have the same on amigaos4. If i run in window mode, and then swith to fullscreen, i limited to rectangle area and can't move mouse outside of this rectangle area. I use SDL 2.0.20

And the same for me as for ctoroman, "ctrl+m" fix issue.

By default i do no know in what window size it runs (probabaly something like 640x480), but when i hit alt+enter, it switch to 1920x1080 full screen (just like my desktop fullscreen), and there i limited to something like 1142 x 752, so "settings" string is the last one i can access to by mouse.

Once hit ctrl+m, then everything start to be correct.

[kas1e]

@All
And actually it happens not only in Myst3. Also in Longest Journey too and probabaly in all other OpenGL games as well then ..

[ccawley2011]

This should be fixed by ​PR #3826.

[ctoroman]

Yes, now fixed! Thanks a lot!

[eriktorbjorn]

That pull request seems to fix the problem for me too.

[kas1e]

Yeah, for me things fixed too, thanks!