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 change removes the "Shared" component from the Windows 8.1 and Windows
Phone 8.1 project files, then renames the projects to use a file structure
that's the same as used for the Windows 8.0 and Windows Phone 8.0 projects.
This change now places WinRT projects in the following directories:
VisualC-WinRT\WinRT81_VS2013\ -- Windows 8.1 project files
VisualC-WinRT\WinPhone81_VS2013\ -- Windows Phone 8.1 project files (NEW, as of this change)
VisualC-WinRT\WinRT80_VS2012\ -- Windows 8.0 project files
VisualC-WinRT\WinPhone80_VS2012\ -- Windows Phone 8.0 project files
Windows 8.0 and Windows Phone 8.0 projects, as well as apps or libs that
reference these, should be unaffected by this change.
Windows 8.1 and Windows Phone 8.1 based apps or libs that reference SDL's
projects directly will need to have their old references removed, then
replaced with new ones that point to the updated structure.
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 commit also includes some base-level support for Universal apps.
TODO:
- add support for Windows Phone 8.1
- add support for satellite libs: SDL_image, SDL_ttf, and SDL_mixer
Setting the tag type will let libtool work even when it cannot infer
the type of the code being built. One way libtool may fail to infer
the tag type is if one uses a mock compiler (such as for static
analysis).
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.
