I see the Remarks of function SDL_BlitSurface shows that "when SDL_BLENDMODE_BLEND, we have dstA = srcA + (dstA * (1-srcA))". however, I tested some pictures but the result implies "dstA=arcA" actually. I stepped into the source code, and found after I set SDL_BLENDMODE_BLEND for the source surface, the final blit function is BlitRGBtoRGBPixelAlphaMMX when I use SDL_BlitSurface on my computer. And I found these codes:
else if (alpha == amask) {
/* opaque alpha -- copy RGB, keep dst alpha */
*dstp = (*srcp & chanmask) | (*dstp & ~chanmask);
The same code is used in BlitRGBtoRGBPixelAlphaMMX3DNOW and BlitRGBtoRGBPixelAlpha. So I think they still keep dst alpha.
Best regards,
Jianyu Guan
If the app is in landscape mode and the user presses the power button, a pause
is followed immediately by a surfaceChanged event because the lock screen
is shown in portrait mode. This triggers a "false" resume.
So, we just pause and resume following the onWindowFocusChanged events.
Also, wait for SDL_APP_WILLENTERBACKGROUND and SDL_APP_DIDENTERBACKGROUND before
blocking the event pump.
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!
