SDL_LoadObject on Windows now calls LoadLibrary a second time in its EX form whenever the first load fails. This second call uses the "altered" search path for DLL dependencies, which includes searching the directory that the DLL itself lives in.

Moved D3D_LoadDLL and SDL_Direct3D9GetAdapterIndex to SDL_windowswindow.c at Jorgen's insistence. That file is wrapped in a more appropriate define check so it will work if somebody builds a binary without D3D support.

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

Do not use UDEV references in EVDEV if UDEV has not been detected

Fixed bug 1820 - building SDL as a static library with static runtime doesn't compile/link with visual studio

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.

Raspberry Pi support (also unified UDEV and EVDEV support)

Fixed doxygen warning.

Corrected name of SDL_Color field from unused to a.

Fixed bug 2101 - CWBackPixel causes weird window flickering on window resize

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.

# User Darren Salt <devspam@moreofthesa.me.uk>
# 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.)

Fixed bug 2100 - directfb fails to build