Closed sulix closed 2 years ago
Thanks for the request. However, I'll put this on hold for a little while until I get it properly tested on Windows, macOS and Linux (all in normal DPI and high-DPI modes). I have a feeling it could break something, so I don't want to pull it just yet. Also I need to get Linux set up on my second laptop and stuff before I can test this.
The current display/mouse code is a mess, it has been hacked over and over to fix issues, so it might not make a lot of sense (or even work properly, for that matter).
Merged it now, after testing that it works fine.
This is a follow-up to the Wayland mouse offset issue in #21 — mouse offset issues were still present on High-DPI Wayland setups (notably in non-stretched fullscreen). The change below fixes the issue (by moving the DPI-handling code out from behind an
#ifdef __APPLE__
check, and fixes a few minor issues with it (none of which were causing problems for me, but theoretically could).The "DPI hack" for Apple Retina systems is actually necessary for all high-DPI systems. Enable it unconditionally — it's harmless on non-high-DPI systems — and clean it up a little. In particular:
Note that, in the soon-to-be-released SDL 2.0.18, the helper function SDL_RenderWindowToLogical() could probably replace a lot of this. (Similarly, the use of SDL_SetWindowMouseRect() will make more sense instead of warping for the software cursor case), but those should wait until after 2.0.18 is fully released and available.
I confesss, I don't really understand the use of the current desktop mode and mouse coordinates everywhere — my feeling is that settings video.useDesktopMouseCoords to false unconditionally should be more stable, even on non-Wayland systems — but I've not changed that here, just in case there's something I'm missing.