- moved SDL_WinRTApp.* from src/video/windowsrt/ to src/core/winrt/, and renamed them to SDL_winrtapp.* (to mimick case-sensitivity used elsewhere in SDL)
- renamed all "windowsrt" directories (in src) to "winrt", as the shorthand name is used more often (and, IMO, "WinRT" != "Windows RT", not entirely at least)
norfanin
SetupWindowData in SDL_windowswindow.c doesn't initialize two members of SDL_WindowData with NULL. This is an issue because other parts of the SDL code seem to make the assumption that this is the case. WIN_DestroyWindowFramebuffer for example uses data->mdc and data->hbm if they're not NULL.
Lloyd Bryant
SDL_CreateTexture() is succeeding (i.e. returning a valid pointer) when the requested horizontal or vertical size of the texture exceeds the maximum allowed by the render. This results in hard-to-understand errors showing up when later attempting to use that texture (such as with SDL_SetRenderTarget()).
Added a reference to SDL_Direct3D9GetAdapterIndex to SDL_test_common.c so SDL will fail to compile if the new symbol isn't included properly.
CR: Jorgen
norfanin
Adds a condition so only the MSVC 2012 compiler defines the macros for the functions of its version.
Attaching a patch that adds a condition so that the HAVE_X supported by MSVC 2012 only get defined with that compiler. MSVC 2008 and 2010 will then build without any modification to the SDL source code.
Also moved HAVE_M_PI to a separate check. The Microsoft headers require _USE_MATH_DEFINES to be defined before they define the constants.
aBothe
I tried to experiment a bit with SDL2 and OpenGL today and noticed that something caused some weird flickering when resizing my nicely drawn SDL2/OpenGL window:
Just after resizing, the background went black and I had to let my OpenGL code redraw the contents..
However, after some hours spent with googling I found out that in OpenGL examples where this CWBackPixel flag was not used when creating X windows, there was no flickering while resizing the window.
See http://www.sbin.org/doc/Xlib/chapt_04.html @ "The Window Background" for more info.
# Date 1379621782 -3600
# Thu Sep 19 21:16:22 2013 +0100
Work around a false-positive in the X11 mouse wheel code
This false positive occurs when one particular button on my mouse is
pressed. The kernel which I'm using is patched to cause a release event to
be synthesised immediately when the mouse says that this button is pressed
because the mouse doesn't signal release until the button is next pressed.
(Also documents a false negative, observed with the horizontal scroll wheel
on the same mouse.)
X11_RestoreWindow() had a call ordering problem that prevented activation, and X11_RaiseWindow() wasn't attempting activation. Windows and OS X both activate in these cases.
CR: saml
