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.
Some more recent compilers emit SSE aligned store instructions for the loop,
causing crashes if the destination buffer isn't aligned on a 32-bit boundary.
This would also crash on platforms like ARM that require aligned stores.
This fixes a crash inside SDL_FillRect that happens with the official x64 mingw
build.
The Windows Phone 8.1 'MessageDialog' API only seems to support two buttons,
despite the documentation for such mentioning support for three. Trying to use
three or more buttons leads to an exception being thrown. As such, any attempt
to use more than two buttons via SDL_ShowMessageBox (on Windows Phone 8.1) will
lead to no message box getting shown, and the call returning an error.
The Win32 MessageBox and dialog APIs are not available in WinRT apps, to note.
More extensive message dialog support might be available at some point, if and
when XAML support is more fully fleshed-out. I'm not certain of this, though.
When a Windows Phone 8.0 app was rotated to anything but Portrait mode, touch
input coordinates, as well as virtual mouse coordinates, were usually getting
reported as coming from the wrong part of the screen.
If a Windows Phone 8.1 device was rotated to anything but Portrait mode,
the Direct3D 11 renderer's output wouldn't get aligned correctly with the
screen.
This is a step towards supporting "Universal" Windows apps, when building for
Windows Phone. SDL can now build against the Windows Phone 8.1 SDK, and apps
linked to it can run, however further work and testing is required as some
previously Phone-only code appears to no longer be applicable for
Windows Phone 8.1. The Windows 8.1 code paths does seem to be preferable, but
should probably be tested and updated on a finer-grained basis.
If in doubt, use the Windows Phone 8.0 projects for now, as located in
VisualC-WinRT/WinPhone80_VS2012/
TODO:
- look at any Windows Phone specific code paths in SDL, and see if Phone 8.1
should use the Windows Phone code path(s), or the Windows 8.x or 8.1 paths
The Win32 APIs, VerifyVersionInfoW and VerSetConditionMask, are not currently
available for use in WinRT apps. This change primarily #if[n]defs-out some
calls to them.
This allows the joystick hotplug to function without the main event loop
(specifically: without SDL_INIT_VIDEO), and moves explicit polling for
joysticks where it belongs at the low-level: in SDL_SYS_JoystickDetect().
This lets apps call SDL_JoystickUpdate() to get hotplug events and keep
SDL_NumJoysticks() correct, as expected. As SDL_PumpEvents() (and
SDL_PollEvents, etc) calls SDL_JoystickUpdate(), existing apps will function
as before.
Thanks to "raskie" on the forums for pointing this out!
This fixes a bug where we'd offset positions by the height of the dock, if it
was along the bottom of the screen.
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2509
Thanks to Alex Szpakowski for bug & patch.
It used to be that SDL_SetWindowPosition was relative to the top of the screen,
which didn't make sense. In addition, borderless windows can be positioned
*below* the menubar, so SDL_SetWindowPosition(win, 0, 0) on a borderless window
would hide ~30ish pixels of the window below the menubar.
This fixes an issue where an empty cliprect is treated the same as a NULL
cliprect, causing the render backends to disable clipping.
Also adds a new API, SDL_RenderIsClipEnabled(render) that allows you to
differentiate between:
- SDL_RenderSetClipRect(render, NULL)
- SDL_Rect r = {0,0,0,0}; SDL_RenderSetClipRect(render, &r);
Fixes https://bugzilla.libsdl.org/show_bug.cgi?id=2504
