configure wraps this C code in a main() function, so you can't declare a
function body in there. Besides, I'm not sure why we declared a function
that's part of the multitouch API anyhow.
Now we just reference a type that only exists if the headers have multitouch
support and call it a day.
SDL was expected that each SDL_DisplayMode had a driverdata field that was SDL_malloc'ed, and was calling SDL_free on them. This change moves WinRT's driverdata content into a SDL_malloc'ed field.
Yamagi
A customer of mine had the strange problem, that SDL_SetRelativeMouseMode() was failing for him on Windows 7. Luckily he was willing to provide some debug informations. We could track this problem down to RegisterRawInputDevices() failing due to security software running on his system (Norton Internet Security to be precise, but there are reports of similar problems with other products. For example [1]). Working around this issue with SDL_WarpMouseInWindow() is easy, and while I don't think that SDL2 can provide an internal workaround it would be really nice and helpfull if this could be documentated somewhere.
1: http://forums.codeguru.com/showthread.php?498374-How-to-run-a-very-long-SQL-statement
Coriiander
In src\timer\windows\SDL_systimer.c there is an error with regards to timeBeginPeriod and timeEndPeriod. These functions typically get called when no high resolution timer is available, and GetTickCount is not used.
According to MSDN (link: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757624(v=vs.85).aspx), for every call to timeBeginPeriod a subsequent call to timeEndPeriod is required. While SDL is currently doing this, it fails to call timeEndPeriod when cleaning up/shutting down SDL. Please note that these functions affect things on a system level. Failing to call timeEndPeriod, disables applications for using WINMM-timers after usage&shutdown of SDL, as effectively they the mechanism is now broken.
Solution:
Ensure this code gets called when shutting down the timer subsystem:
#ifndef USE_GETTICKCOUNT
if (!hires_timer_available)
{
timeSetPeriod(0);
}
#endif
This makes it possible to move windows by their title bar, even if they're in
relative mode, if you click the title bar when the window does not have focus.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2396
Previously we were postponing our -[NSOpenGLContext update] call to the next
SDL_GL_SwapWindow, even if the context was current on the current thread. This
changes it so that we will do the update immediately if it's the current
context.
If you're rendering on another thread, you need to call SDL_GL_SwapWindow once
after a resize event to ensure your drawable will produce non-garbage data.
Bug: https://bugzilla.libsdl.org/show_bug.cgi?id=2339
If the window has been created with values for SDL_GL_CONTEXT_PROFILE_MASK,
SDL_GL_CONTEXT_MAJOR_VERSION and SDL_GL_CONTEXT_MINOR_VERSION not matching those
required by the renderer, attempt to recreate the window.
This is needed on platforms where both GL and GLES 1/2 surfaces are supported
by the video backend, requiring that the window be recreated when switching
between context types.
Pressing the hardware back button on a Windows Phone 8 device will now cause SDL to emit a pair of key-down and key-up events, with the SDL scancode, SDL_SCANCODE_AC_BACK.
By default, if WinRT's native back-button-press events are not explicitly marked as 'handled', then Windows Phone will terminate the app. More details on Microsoft's reasoning behind this can be found on MSDN, at http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj247550(v=vs.105).aspx
To mark back-button-press events as 'handled', set SDL_HINT_WINRT_HANDLE_BACK_BUTTON to 1. Setting it to anything else will cause these events to not be marked as 'handled'.
Due to limitations in Windows Phone's APIs, SDL will emit a virtual key-up event immediately after the back button's key-down event is registered. Unfortunately, Windows Phone 8 only allows one to register for back-button-press events, and not back-button-release events.
This change is only relevant for Windows 8, 8.1, and RT apps, and only for those that are network-enabled. Such apps must feature a link to a privacy policy, which must be displayed via the Windows Settings charm. This is needed to pass Windows Store app-certification.
Using SDL_SetHint, along with SDL_HINT_WINRT_PRIVACY_POLICY_URL and optionally SDL_HINT_WINRT_PRIVACY_POLICY_LABEL, will cause SDL/WinRT to create a link inside the Windows Settings charm, as invoked from within an SDL-based app.
Network-enabled Windows Phone apps do not need to set this hint, and should provide some sort of in-app means to display their privacy policy. Microsoft does not appear to provide an OS-integrated means for displaying such on Windows Phone.
The destination target's alpha wasn't getting set correctly in many cases. Among other problems, this prevented some alpha-blended textures from displaying correctly in Windows Phone 8's multitasking screen.
The d3d11 renderer now uses the same blending settings found in the d3d9 renderer.
The projection and view matrices are now computed ahead of time, as they both get computed in the same spot, and typically not often. If this does, however, become a performance problem later on, this change can always be reverted.
Previously, the shaders would get compiled separately, the output of which would need to be packaged into the app. This change should make SDL's dll be the only binary needed to include SDL in a WinRT app.
