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 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.
All WinRT builds of SDL will now output, "SDL2.dll". Previously, the Windows
8.x/RT builds would output, "SDL.dll", and Windows Phone 8 builds would output,
"SDL_WinPhone.dll". The change to "SDL2.dll" puts WinRT dll naming in-line with
that seen on Win32.
SDL/WinRT's MSVC project files will now appear as either "SDL2-WinRT" or
"SDL2-WinPhone", when displaying in MSVC.
This set of changes should not break any older WinRT or Windows Phone 8 app
builds that rely on MSVC's Project-to-Project reference system to build SDL2 for
the correct platform(s), and to install SDL2 dll files into the apps' output
packages. App builds that reference SDL dll files directly should, however,
now reference "SDL2.dll".
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.
Sam Lantinga
Philipp Wiesemann
Ryan C. Gordon
stopiccot
David Ludwig
Pierre-Loup A. Griffais
Brandon Schaefer
Gabriel Jacobo
