SDL_syssem.c:159 comparison of unsigned expression >= 0 is always true
Solved by comparing unsigneds directly
SDL_systimer.c:164: warning: control may reach end of Compile
Solved by returning the default value if all else fails.
SDL_androidgl.c:41:1: warning: type specifier missing, defaults to 'int'
SDL_androidgl.c:47:1: warning: control reaches end of non-void function
Solved by adding void return type to the function implementation
Make it so XInput devices are listed before DirectInput devices, and that the XInput
devices are sorted by userid in ascending numeric order (so device 0 comes first).
Now multiple XInput controllers map correctly to device indexes instead of grabbing
the first available userid, and are completely separated out from DirectInput.
Also, the hardcoded limitation on number of DirectInput devices is gone. I don't
expect there to really ever be more than eight joysticks plugged into a machine, but
it was a leftover limitation for a static array we didn't actually use anymore.
Fixes Bugzilla #1984. (etc?)
- also adds OS X specific magic for bundled apps adding an Info.plist property of name SDL_FILESYSTEM_BASE_DIR_TYPE to the following values will change the bahaviour.
* bundle -- use the bundle directory e.g. "/Applications/MyGame/Blah.app/"
* parent -- use the bundle parent directory e.g. "/Applications/MyGame/"
* resource -- use the bundle resource directory (default) e.g. "/Applications/MyGame/Blah.app/Contents/Resources/"
- detect that you tried to open a gamecontroller in xinput mode and failed, then re-get the mapping for the dinput variant you did open (and most likely now just fail the open)
CR: SamL
This entire function is kind of a mess and more complicated than needed, but I don't want to refactor it too heavily tonight. May look at improving how the indexes are assigned more significanly later. The way it handles not finding a valid "gamepad" type device is also super broken, it leaves in place the xinput bindings but opens the controller with dinput and ends up with completely wrong mappings, not solving that now, but fixing the bug where we'd very frequently not find a controller due to gaps in assigned player numbers should mostly avoid it.
Andreas
The issue comes down to this line on MSDN:
"TranslateMessage produces WM_CHAR messages only for keys that are mapped to ASCII characters by the keyboard driver."
"WM_KEYDOWN and WM_KEYUP combinations produce a WM_CHAR or WM_DEADCHAR message. WM_SYSKEYDOWN and WM_SYSKEYUP combinations produce a WM_SYSCHAR or WM_SYSDEADCHAR message."
Except for WM_CHAR, none of these messages are used in SDL. Hence TranslateMessage should be dropped entirely and proper handling be included in the WM_KEYDOWN event.
Currently TranslateMessage is called for every message even if it must not be called in certain cases (like "An application should not call TranslateMessage if the TranslateAccelerator function returns a nonzero value.").
WM_CHAR message handling should remain for external processes posting these messages - additionally, WM_UNICHAR should be added.
I made a patch for src/video/windows/SDL_windowsevents.c that seems to work fine. It doesn't solve the "missing" composition for Khmer, but at least input for languages that cannot be mapped to ASCII characters (and for which IME is not used) will now work on Windows.
Jianyu Guan
I found I make a big mistake that when dstA==0, I just simply let *dstp=*srcp and forgot to make dstRGB = srcRGB*srcA.
The if consition "(*dstp & amask) == 0" in BlitRGBtoRGBPixelAlphaMMX and BlitRGBtoRGBPixelAlphaMMX3dNow should be removed.
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.
