This is part of an overall effort to use the name, "WinRT", rather than "WindowsRT" (or "Windows RT"), as the shorthand name often seems to mean something different than the longhand name. (WinRT is an API, Windows RT is a product name)
This change removes some code that attempted to allow non-standard window sizes, the idea of which was to do display scaling, and a hackish one at that. If display scaling is needed, use SDL_Renderer as appropriate.
- 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.)
