Sun, 10 Dec 2017 09:17:33 -0800Workaround for bug 3931 - spurious SDL_MOUSEMOTION events with SDL_HINT_MOUSE_RELATIVE_MODE_WARP 1 since Windows 10 Fall Creators update default tip
Sam Lantinga <slouken@libsdl.org> [Sun, 10 Dec 2017 09:17:33 -0800] rev 11758
Workaround for bug 3931 - spurious SDL_MOUSEMOTION events with SDL_HINT_MOUSE_RELATIVE_MODE_WARP 1 since Windows 10 Fall Creators update

Elisée Maurer

The attached minimal program sets the SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1, enables relative mouse mode then logs all SDL_MOUSEMOTION xrel values as they happen.

When moving the mouse exclusively to the right:

* On a Windows 10 installation before Fall Creators update (for instance, Version 10.0.15063 Build 15063), only positive values are reported, as expected
* On a Windows 10 installation after Fall Creators update (for instance, Version 10.0.16299 Update 16299), a mix of positive and negative values are reported.

3 different people have reproduced this bug and have confirmed it started to happen after the Fall Creators update was installed. It happens with SDL 2.0.7 as well as latest default branch as of today.

It seems like some obscure (maybe unintended) Windows behavior change? Haven't been able to pin it down more yet.

(To force-upgrade a Windows installation to the Fall Creators update, you can use the update assistant at https://www.microsoft.com/en-us/software-download/windows10)

Eric Wasylishen

Broken GetCursorPos / SetCursorPos based games on Win 10 fall creators are not limited to SDL.. I just tested winquake.exe (original 1997 exe) and it now has "jumps" in the mouse input if you try to look around in a circle. It uses GetCursorPos/SetCursorPos by default. Switching WinQuake to use directinput (-dinput flag) seems to get rid of the jumps.

Daniel Gibson

A friend tested on Win10 1607 (which is before the Fall Creators Update) and the the bug doesn't occur there, so the regression that SetCursorPos() doesn't reliably generate mouse events was indeed introduced with that update.
I even reproduced it in a minimal WinAPI-only application (https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68), the weird thing is that if you don't do anything each "frame" (i.e. the mainloop only polls the events and does nothing else), there are a lot of mouse events with the coordinates you passed to SetCursorPos(), but when sleeping for 10ms in each iteration of the mainloop, those events basically don't happen anymore. Which is bad, because in games the each iteration of the mainloop usually takes 16ms..

I have a patch now that I find acceptable.
It checks for the windows version with RtlGetVersion() (https://msdn.microsoft.com/en-us/library/windows/hardware/ff561910.aspx) and only if it's >= Win10 build 16299, enables the workaround.
All code is in video/windows/SDL_windowsevents.c
and the workaround is, that for each WM_MOUSEMOVE event, "if(isWin10FCUorNewer && mouseID != SDL_TOUCH_MOUSEID && mouse->relative_mode_warp)", an addition mouse move event is generated with the coordinates of the center of the screen
(SDL_SendMouseMotion(data->window, mouseID, 0, center_x, center_y);) - which is exactly what would happen if windows generated those reliably itself.
This will cause SDL_PrivateSendMouseMotion() to set mouse->last_x = center_x; and mouse->last_y = center_y; so the next mouse relative mouse event will be calculated correctly.

If Microsoft ever fixes this bug, the IsWin10FCUorNewer() function would have to
be adjusted to also check for a maximum version, so the workaround is then disabled again.

Sun, 10 Dec 2017 09:10:02 -0800Added SDL_WinRTGetDeviceFamily() to find out what type of device your application is running on (thanks Daniel Knobe!)
Sam Lantinga <slouken@libsdl.org> [Sun, 10 Dec 2017 09:10:02 -0800] rev 11757
Added SDL_WinRTGetDeviceFamily() to find out what type of device your application is running on (thanks Daniel Knobe!)

Sun, 10 Dec 2017 09:09:27 -0800Added the Metal framework to several iOS tests
Sam Lantinga <slouken@libsdl.org> [Sun, 10 Dec 2017 09:09:27 -0800] rev 11756
Added the Metal framework to several iOS tests

Sat, 09 Dec 2017 19:48:38 -0800Backed out using pixel texture coordinates, it had weird visual side effects
Sam Lantinga <slouken@libsdl.org> [Sat, 09 Dec 2017 19:48:38 -0800] rev 11755
Backed out using pixel texture coordinates, it had weird visual side effects

Sat, 09 Dec 2017 19:41:08 -0800Fixed normalized coordinates when the viewport is set
Sam Lantinga <slouken@libsdl.org> [Sat, 09 Dec 2017 19:41:08 -0800] rev 11754
Fixed normalized coordinates when the viewport is set

Sat, 09 Dec 2017 15:00:41 -0800Added support for linear sampling and pixel coordinates in the metal renderer
Sam Lantinga <slouken@libsdl.org> [Sat, 09 Dec 2017 15:00:41 -0800] rev 11753
Added support for linear sampling and pixel coordinates in the metal renderer

Sat, 09 Dec 2017 13:05:56 -0800Fixed compiler warning
Sam Lantinga <slouken@libsdl.org> [Sat, 09 Dec 2017 13:05:56 -0800] rev 11752
Fixed compiler warning

Sat, 09 Dec 2017 12:58:41 -0800Fixed pixel positioning and size for the Metal renderer
Sam Lantinga <slouken@libsdl.org> [Sat, 09 Dec 2017 12:58:41 -0800] rev 11751
Fixed pixel positioning and size for the Metal renderer

Sat, 09 Dec 2017 03:28:23 -0500metal: fixed render target support.
Ryan C. Gordon <icculus@icculus.org> [Sat, 09 Dec 2017 03:28:23 -0500] rev 11750
metal: fixed render target support.

Sat, 09 Dec 2017 03:27:52 -0500metal: Added some comments and FIXMEs.
Ryan C. Gordon <icculus@icculus.org> [Sat, 09 Dec 2017 03:27:52 -0500] rev 11749
metal: Added some comments and FIXMEs.