On Windows 10, apparently since the “Fall Creators Update”, relative mouse mode via warping (instead of Raw Input) is unusably broken - SDL events are created, but don’t behave like expected - https://www.youtube.com/watch?v=Yl9QMMNuTSk shows this in action: you can’t really look around with the mouse, it seems to (mostly) jerk back to the original position.
This can be reproduced (if you’re on Win10 with that update) with the
SDL_HINT_MOUSE_RELATIVE_MODE_WARP hint (or the corresponding
SDL_MOUSE_RELATIVE_MODE_WARP environment variable) set to 1.
The biggest problem with this is that for some people relative mouse mode via raw input fails (i.e.
RegisterRawInputDevices() fails) and up to now those people didn’t even notice that because SDL falls back to warping which worked well enough.
I’m not sure what makes raw input fail; one possibility is “security” software like “Norton Internet Security” which somehow disallows raw input (see https://bugzilla.libsdl.org/show_bug.cgi?id=2368), but for Yamagi Quake II we have a user who claims to only use “Microsoft Security Essentials” (which seems to not break raw mouse input for others) and still seems to get the broken relative mouse mode (see https://github.com/yquake2/yquake2/issues/257 - I’m still waiting for more feedback there to hopefully narrow down why
RegisterRawInputDevices() fails and if it really fails).
A bugreport for this already exists: https://bugzilla.libsdl.org/show_bug.cgi?id=3931
It seems like the Windows update broke
GetCursorPos() and this doesn’t only affect SDL2, but also SDL1.2 (>= 1.2.14 - always, not just when some environment variable is set) and the old winquake.exe from 1997 (thanks to @Eric_Wasylishen for figuring that out!).
I’m posting this here to get more awareness of this problem.
As this apparently is a regression in Windows, does anyone know any developer at Microsoft who could get this to the right people so it may get fixed on their side?