Eventually we'll probably move the version checking to higher level code and report the actual version of context that got created, but to avoid breakage we'll leave it like this for now.
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
klose
File: SDL_gesture.c
Method: SDL_GestureAddTouch
When a new SDL_GestureTouch element is added to the global SDL_gestureTouch array the variable 'centroid' of the new element is not initialized.
The problem is that this variable is read isndie SDL_GestureProcessEvent when a SDL_FINGERDOWN event occurs.
- SDL_WINDOW_FULLSCREEN works as always (change resolution, lock to window).
- SDL_WINDOW_FULLSCREEN_DESKTOP now puts the window in its own Space, and
hides the menu bar, but you can slide between Spaces and Command-Tab between
apps without the window minimizing, etc.
- SDL_WINDOW_RESIZABLE windows will get the new 10.7+ "toggle fullscreen"
window decoration and menubar item. As far as the app is concerned, this is
no different than resizing a window, but it gives the end-user more power.
- The hint for putting fullscreen windows into the Spaces system is gone,
since Spaces can't enforce the requested resolution. It's a perfect match
for FULLSCREEN_DESKTOP, though, so this is all automated now.
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.