Tue, 03 Jun 2014 21:13:00 -0700 X11: Provide specific X error when SDL_GL_CreateContext fails.
Jørgen P. Tjernø <jorgen@uberent.com> [Tue, 03 Jun 2014 21:13:00 -0700] rev 8804
X11: Provide specific X error when SDL_GL_CreateContext fails. This makes the X error handler used for GL context creation handle *all* errors and provide the user with specific error messages when SDL_GL_CreateContext fails. CR: icculus@icculus.org
Mon, 02 Jun 2014 09:20:09 -0700 Hopefully really fixed the Android build
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:20:09 -0700] rev 8803
Hopefully really fixed the Android build
Mon, 02 Jun 2014 09:12:51 -0700 Fixed Android build
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:12:51 -0700] rev 8802
Fixed Android build
Mon, 02 Jun 2014 09:09:40 -0700 Fixed bug 2534 - Mac: black bar at top of screen in SDL_WINDOW_FULLSCREEN mode
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:09:40 -0700] rev 8801
Fixed bug 2534 - Mac: black bar at top of screen in SDL_WINDOW_FULLSCREEN mode Alex Szpakowski Patch to fix the y component of the position of fullscreen windows in OS X. In Mac OS X with the latest Mercurial code, when a window is in exclusive-fullscreen the y component of its position is offset by the same amount that is normally taken up by the menubar, resulting in a black bar at the top of the screen. The recent changes to the internal ConvertNSRect function make it treat the bottom of the menubar as 0 for the y component of window positions, even when the window is fullscreen and 'above' the menubar. I have attached a patch which fixes the issue by only making the window position relative to the menubar in windowed modes.
Mon, 02 Jun 2014 09:06:38 -0700 Fixed bug 2550 - [OS X 10.9] Enabling SDL_WINDOW_FULLSCREEN after relative mouse mode leaves cursor visible
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:06:38 -0700] rev 8800
Fixed bug 2550 - [OS X 10.9] Enabling SDL_WINDOW_FULLSCREEN after relative mouse mode leaves cursor visible Eric Wasylishen Steps to reproduce: - Run testwm2 app in the SDLTest Xcode project - Press Control+R to enable relative mouse mode. The mouse cursor should disappear. - Press Control+Enter to enter fullscreen. - Expected: a black screen with no cursor visible. Observed: a black screen, but the mouse cursor is visible in the middle of the screen. It doesn't move when I move the mouse. Reproduced with latest sdl2 hg (changeset 29aac8b813d9) on OS X 10.9.2. Can't reproduce the problem on OS X 10.6.8 or 10.7.5. I'm speculating that this really an Apple bug.. but anyway, the attached workaround seems to fix it for me, and I think it's fairly safe. A more obvious idea, sticking a call SDL_SetCursor(NULL) at the end of Cocoa_SetWindowFullscreen, didn't work.
Mon, 02 Jun 2014 09:01:26 -0700 Added a way to get the native Android window and EGL context
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:01:26 -0700] rev 8799
Added a way to get the native Android window and EGL context
Mon, 02 Jun 2014 09:01:10 -0700 Fixed bug 2479 - [OS X] SDL_SetWindowFullscreen fails to switch to windowed
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 09:01:10 -0700] rev 8798
Fixed bug 2479 - [OS X] SDL_SetWindowFullscreen fails to switch to windowed Eric Wasylishen The problem seems to be the spaces handling code in -setFullscreenSpace: (SDL_cocoawindow.m) is incorrectly reporting that the SDL_WINDOW_FULLSCREEN -> windowed transition has already happened. i.e. I saw this case was getting hit when trying to leave SDL_WINDOW_FULLSCREEN: "else if (state == isFullscreenSpace) { return YES; /* already there. */ }" With the attached patch, both Control+Enter (SDL_WINDOW_FULLSCREEN toggle) and Option+Enter (SDL_WINDOW_FULLSCREEN_DESKTOP toggle) work in an sdl test app (I tried testwm2). Tested on OS X 10.9.2.
Mon, 02 Jun 2014 08:58:07 -0700 Don't use D3D9Ex by default, since it can change behavior for games which rely on D3D9 classic.
Sam Lantinga <slouken@libsdl.org> [Mon, 02 Jun 2014 08:58:07 -0700] rev 8797
Don't use D3D9Ex by default, since it can change behavior for games which rely on D3D9 classic.
Sat, 31 May 2014 14:03:04 -0700 Fixed bug 2520 - Held double-click app startup creates a stuck MOUSEBUTTONDOWN event
Sam Lantinga <slouken@libsdl.org> [Sat, 31 May 2014 14:03:04 -0700] rev 8796
Fixed bug 2520 - Held double-click app startup creates a stuck MOUSEBUTTONDOWN event snake5creator When starting application with the usual "double click on file" method on Windows, only holding the last click, an unnecessary MOUSEBUTTONDOWN event is sent before the initial MOUSEMOTION event, and mouse button state is stuck in the sense that it takes a subsequent button release, followed by another press for the system to resume sending events (beginning with the next button release / MOUSEBUTTONUP event). Input event log with held double-click startup: http://i.imgur.com/nypGKR2.png Without: http://i.imgur.com/yaIqAvV.png
Sat, 31 May 2014 12:21:55 -0700 Fullscreen to windowed mode switch
Sam Lantinga <slouken@libsdl.org> [Sat, 31 May 2014 12:21:55 -0700] rev 8795
Fullscreen to windowed mode switch From Melesie I noticed that when user switches from fullscreen mode to windowed mode and exits application while in windowed mode, Windows performs an additional change of display settings, even though desktop resolution is the same as current one. This causes short black screen to show up. The only way I know of avoiding this is to explicitly switch to default display settings found in registry. MSDN documentation for ChangeDisplaySettingsEx states: Passing NULL for the lpDevMode parameter and 0 for the dwFlags parameter is the easiest way to return to the default mode after a dynamic mode change.
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip