MacOS Full screen mouse alignment

[utechtl]

Operating System

MacOS 14.4.1

OpenRCT2 build

OpenRCT2, v0.4.11 (18d2b5e on HEAD)

Base game

RollerCoaster Tycoon 2

Area(s) with this issue?

This bug is a graphical glitch or error

Describe the issue

When launching the game from previously being in full screen (green mac full screen button, not the in-game full screen mode) the highlight doesn't match the cursor.

Steps to reproduce

1. Make game full screen via the green mac full screen window.
2. close game
3. relaunch later

Attachments

Link to video of issue, too big for github

[AaronVanGeffen]

I'm having the same issue. Wonder if it's related to SDL having been updated in #21771 (cc @janisozaur)

[astraylife1]

This happened to me after making it full screen. Cannot fix it, even after deleting and downloading latest release again.

[janisozaur]

Is the offset constant?

[AaronVanGeffen]

No, it appears to vary depending on how far into the window you are. Happens regardless of window scaling though.

[janisozaur]

I think this is a showstopper and I'm trying to fix it.

So far I tried inspecting what changed between https://github.com/microsoft/vcpkg/compare/c9f906558f9bb12ee9811d6edc98ec9255c6cda5..11ed79186fe850bd3a98cfbf1854514d2b3070a2 and create a libraries release on each "interesting" version:

git lol c9f906558f9bb12ee9811d6edc98ec9255c6cda5..11ed79186fe850bd3a98cfbf1854514d2b3070a2 ports/sdl2/ ports/breakpad/ ports/libressl SDL2 is primary suspect for this regression breakpad is for https://github.com/OpenRCT2/OpenRCT2/issues/22003 libressl did not initially support arm and broke builds. I have eventually disabled networking in my OpenRCT2 trial builds.

Unfortunately, building OpenRCT2 with all the libraries that got built (not all commits have) fails due to libicu not providing required components.

Next steps: figure out if I can just redirect vcpkg to an older version of port. The overall idea is to find release that introduced regression and then perform bisect. I hope to learn what changed in SDL code and then either adapt our code to new version or send the fix upstream if necessary.

[janisozaur]

I managed to create some test builds with older SDL2 versions, please test each one if the bug is present.

https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.26.5.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.28.2.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.28.3.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.28.4.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.28.5.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.30.0.zip https://github.com/janisozaur/OpenRCT2/releases/download/v21973/openrct2-macos-sdl2-2.30.1.zip

[AaronVanGeffen]

It's already present in openrct2-macos-sdl2-2.26.5.zip for me??

[AaronVanGeffen]

I renamed my config.ini to config_bad.ini, restarted OpenRCT2, and had no problems. Moving settings back in, I narrowed it down to the following issue:

 $ diff -u config_{bad,good}.ini
--- config_bad.ini  2024-05-12 20:26:11
+++ config_good.ini 2024-05-12 22:35:20
@@ -22,7 +22,7 @@
 debugging_tools = true
 show_height_as_units = false
 temperature_format = CELSIUS
-window_height = 945
+window_height = 940
 window_snap_proximity = 5
 window_width = 1512
 default_display = 0

Changing 940 to 940 fixed the problem. Changing to 944 did not, so it's not just a factor of two problem. It seems to be related to having a remainder after division.

Question is, how do we prevent the window size to get to these 'bad' values? Perhaps we can keep them clamped to particular factors, somehow?

[janisozaur]

My guess this is because the height (what about width?) is not a multiple of the scaling factor that OS uses. Maybe it's not the window size, but renderer size which then gets squished or something? If we asked SDL or the system about then maybe we could stick to save values

[utechtl]

Sorry, I was out of town for the weekend. Thanks for taking a look at this already.

I've found a few quirks while poking at this;

1. The issue persists between the 6 test builds.
2. It appears that the offset between cursor and where the game thinks it is scales with the height but not width of the screen, ie purely offset in the vertical direction.
3. The issue happens regardless of the OS screen resolution (1024x666, 1280x832, 1470x956, and 1710x1112).
4. Changing from Windowed mac full screen (Green button) to the full screen ORCT fullscreen dropdown crashes the game instantly but un-maximzing it first doesn't. It's probably a separate issue.
5. For sure another separate issue but once every ~20 launches maybe, I get the Beach ball of death while I wait for the game to load. Normally the game launches almost instantly.

[janisozaur]

So does this issue happen with 0.4.10 as well then?

[janisozaur]

@AaronVanGeffen confirmed this is not a new issue. As such, I'm lowering it's priority. I still consider this quite a serious issue, but perhaps amount of people affected is minuscule and it was only reported recently.

[macsnider]

I have the same problem, 0.4.10 is fine, everything above not. 0.4.12 doesn't solve this also.

macOS 14.5 (23F79)

[AaronVanGeffen]

Try resizing the window manually. Problem should go away when the internal resolution is aligned properly with the window manager.