Ronie Salgado
The GL Renderer current context tracking fails when one window is used with an SDL renderer but another separate window is used with a user handled OpenGL context.
Attached is a small program that reproduces this bug, at least in some Linux machines where an OpenGL renderer is provided by default.
Expected Output:
-"First window" should be blue.
-"Second window" should be green.
Gotten Output:
- "First window" black.
- "Second window" blue.
What happened:
The renderer created for the "first window" ends rendering into the "second window" OpenGL context.
Bug location:
SDL_render_gl.c - line 286 on hg:
static SDL_GLContext SDL_CurrentContext = NULL;
When making SDL_GL_MakeCurrent from the user perspective, that variable or the GL renderer is not notified about the OpenGL context change.
Solution proposal:
- Move the current GL context cache into another place global.
Brad Smith
Attached is patch from the OpenBSD ports tree to add 24-bit support to the sndio backend and to make use of the sio_open() option SIO_DEVANY.
Diego
The Xcode Instruments Leak tool reports a leak from IODisplayCreateInfoDictionary in Cocoa_GetDisplayName.
This happened after upgrading to Xcode 5.
Frank Praznik
Add a gamepad mapping entry for Bluetooth DualShock 4 controllers on Linux.
The button mapping is the same as the USB controller, but the GUID is
different.
It was simpler to just have the polling (actually: hotplug detection)
functions return immediately if it's not an appropriate time to poll.
Note that previously, if any joystick/controller was opened, we would poll
every time anyhow, skipping this function.
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
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.
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 f6010ead184f) 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.
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.
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
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.
This would have been a one-line patch to the documentation (specifying that
captures only work as long as the left mouse button is pressed), but I didn't
like that, so I got a little crazy about this instead.
There were several good arguments for this: it's how Windows works with
WM_NCHITTEST, SDL doesn't need to manage a list of rects, it allows more
control over the regions (how do you use rects to cleanly surround a circular
button?), the callback can be more optimized than a iterating a list of
rects, and you don't have to send an updated list of rects whenever the
window resizes or layout changes.
This should be a "long" which on a 64-bit system is likely to be > 32-bits,
causing XGetICValues() to write past the end of the variable (and stack).
Fixes Bugzilla #2513.
It seems like a net improvement in all the scenarios Sam and I could
think of, and looking at hg history it was added for fullscreen
window management specifically. Much of that code has changed since
then, but maybe it needs to stay there for that and simply be moved
to a fullscreen condition check.
It would solve this issue:
https://bugzilla.libsdl.org/show_bug.cgi?id=2439
As well as cases where on SteamOS, we hide/show specific Steam
overlay windows while expecting them to stay in the background, since
changing the window stacking order really angers the NVIDIA driver.
CR: Sam.
(Most of its complaints here are that these ints can be negative, although
they wouldn't been in sane cases. Checking sanity is what assertions do, and
it placates the analyzer appropriately.)
These scenarios can happen when a GPU is switched, its driver updated, or in
some virtual machines (such as Parallels) are suspended and then resumed. In
these cases, all GPU resources will already be lost, and it's up to the app to
recover.
For now, SDL's D3D11 renderer will handle this by freeing all GPU resources,
including all textures, and then sending a SDL_RENDER_TARGETS_RESET event.
It's currently up to an app to intercept this event, destroy all of its
textures, then recreate them from scratch.
SDL_WINDOWEVENT_FOCUS_LOST is now sent when an app's native window is hidden.
Likewise, SDL_WINDOWEVENT_FOCUS_GAINED is sent when an app's window is shown.
This mimicks behavior seen on iOS and Android.
SDL_WINDOWEVENT_MINIMIZED and SDL_WINDOWEVENT_RESTORED are now sent when the
app's native window is hidden and shown. Previously, these were sent when an
app was suspended and resumed. On Windows 8.x/RT, an app may be sent to the
background without being suspended, which previously meant that
SDL_WINDOWEVENT_MINIMIZED might never have been sent. (On Windows Phone 8,
however, this seems to be different, whereby apps sent to the background appear
to always get suspended.)
SDL_APP_WILLENTERBACKGROUND is now sent as soon as the app is told that it is
about to go to the background. SDL_APP_DIDENTERBACKGROUND is sent via a WinRT
'deferral operation', which is how WinRT gives apps a bit of extra time
(multiple seconds worth) to prepare for an app-backgrounding.
The distinction may be important as the deferral operation's code is always run
in a separate thread. For Direct3D-only apps, this means that between the
two SDL app-backgrounded events, SDL_APP_WILLENTERBACKGROUND will be the only
one run from the main thread. Given that some WinRT operations can only be done
on the main thread (operations to the CoreWindow fall into this category), this
could be important.
It is important to note that pre-deferral code may only have a very short bit of
time to execute code, less so than code run in the deferral operation (where
SDL_APP_DIDENTERBACKGROUND is sent from), which usually gets several seconds to
run.
SDL/WinRT did have support for OpenGL ES 2 via an older version of ANGLE/WinRT,
however its API changed a few months ago, and SDL/WinRT would crash when trying
to use it. It would also occasionally crash when using the older version.
This changeset should make SDL/WinRT work with the latest version, as
available via MS Open Tech's git repository of it at
https://github.com/msopentech/angle
Older versions of ANGLE/WinRT (from either https://github.com/stammen/angleproject
or https://bitbucket.org/DavidLudwig/angleproject) will need to be updated to
MS Open Tech's latest version.
