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.
--HG--
extra : rebase_source : 7024be6c3a874d0319ea4c65b7d43f105915288f
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.
PoopiSan
Currently on OSX and iOS simulator the values:
mach_base_info.denom = 1
mach_base_info.numer = 1
but on the real iOS device
mach_base_info.denom = 3
mach_base_info.numer = 125
The calculation is made using following formula
mach_base_info.denom / mach_base_info.numer * 1000000
but all values are int32 and the result is casted to int64.
This solves the problem:
return 1.0 * mach_base_info.denom / mach_base_info.numer * 1000000;
Patrick Maloney
Saitek p2500 (Cyborg Rumble Force Pad) has a D-pad, two analog sticks, and numerous buttons. SDL 2.x on OSX detected everything except the right-side analog stick. The right-side stick is considered a 'simulation device' with the axes mapped to throttle and rudder.
The patch adds support for throttle and rudder on the HID simulation page.
We needed a bit, so we're hoping no one needs this effect, especially when
it's fairly close to SDL_HAPTIC_SINE, we hope.
SDL_HAPTIC_LEFTRIGHT maps to XInput's functionality, so this removes the SINE
code for the XInput driver to keep things clean.
This also makes the simplified Rumble API use SDL_HAPTIC_LEFTRIGHT if
SDL_HAPTIC_SINE isn't available, to keep XInput working.
When we break the ABI, and can extend the supported capabilities field from
a Uint16, we'll add SDL_HAPTIC_SQUARE back in.
This patch is based on work by Ethan Lee.
To fix this we need to ignore the alpha channel in the colorkey comparison, which is the way colorkey comparisons are defined in SDL.
We also need to reset the alpha and color modulation when converting a surface.
If the user is using their context from a non-main thread, we could be
calling -[NSOpenGLContext update] on our thread, while they were
accessing it on their thread.
With this change, we schedule updates when the event comes in on the
main thread, and act on them when the user calls SDL_GL_MakeCurrent or
SDL_GL_SwapWindow.
This uses a better mouse grab if you define SDL_MAC_NO_SANDBOX. This
mouse grab uses CGEventTapCreate, which you cannot access if you have
sandboxing enabled.
From Sythical:
Hello, I've created a simple SDL2 application which draws a texture on the screen. The problem I'm having is that if I launch another program which loads the UAC popup or if I lock my PC and then login again, the application stops drawing the texture. I tried adding SDL_Delay(10000) after SDL_RenderPresent(renderer). This made the texture stay on the screen for a little bit but the texture wasn't drawn again after the delay. Here's my code:
#include "SDL.h"
int main(int argc, char *argv[])
{
SDL_Renderer *renderer;
SDL_Window *window;
SDL_Surface *surface;
SDL_Texture *rect_texture;
SDL_Event main_event;
SDL_Rect rect_data;
int enable_vsync = 1;
if(SDL_Init(SDL_INIT_VIDEO) < 0) return 1;
window = SDL_CreateWindow("SDL2 Application", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 600, 600, SDL_WINDOW_RESIZABLE);
renderer = SDL_CreateRenderer(window, -1, enable_vsync ? SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC : SDL_RENDERER_ACCELERATED);
SDL_SetRenderDrawColor(renderer, 20, 20, 30, 255);
surface = SDL_LoadBMP("icon.bmp");
rect_texture = SDL_CreateTextureFromSurface(renderer, surface);
rect_data.w = 32; rect_data.h = 32;
rect_data.x = 300; rect_data.y = 300;
while(main_event.type != SDL_QUIT)
{
SDL_PollEvent(&main_event);
SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, rect_texture, NULL, &rect_data);
SDL_RenderPresent(renderer);
}
SDL_DestroyTexture(rect_texture);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();
return 0;
}
This prevents a rogue call to SetWindowPos() from changing the state unexpectedly.
Also moved the size correction code above the window position query, because the initial window size can affect the positioning.
