This reverts http://hg.libsdl.org/SDL/rev/7cdeb64faa72 and fixes it in
the correct way. If you call SDL_SetWindowPosition on a fullscreen
window, it would update the x & y variables for the window, but not
actually move the window (since it was fullscreen). That would make the
internal state of the SDL_Window incorrect, causing
SDL_WarpMouseInWindow to offset incorrectly.
This makes it so SDL_SetWindowPosition updates the `windowed' x & y
coordinates, which take effect when you revert from fullscreen.
On Android available touch devices are now added with video initialization (like
the keyboard). This fixes SDL_GetNumTouchDevices() returning 0 before any touch
events happened although there is a touch screen available. The adding of touch
devices after a touch event was received is still active to allow connecting
devices later (if this is possible) and to provide a fallback if the new init
did not work somehow. For the implementation JNI was used and API level 9 is
required. There seems to be nothing in the Android NDK's input header (input.h)
to implement everything on C side without communication with Java side.
This is part of an overall effort to use the name, "WinRT", rather than "WindowsRT" (or "Windows RT"), as the shorthand name often seems to mean something different than the longhand name. (WinRT is an API, Windows RT is a product name)
This change removes some code that attempted to allow non-standard window sizes, the idea of which was to do display scaling, and a hackish one at that. If display scaling is needed, use SDL_Renderer as appropriate.
- moved SDL_WinRTApp.* from src/video/windowsrt/ to src/core/winrt/, and renamed them to SDL_winrtapp.* (to mimick case-sensitivity used elsewhere in SDL)
- renamed all "windowsrt" directories (in src) to "winrt", as the shorthand name is used more often (and, IMO, "WinRT" != "Windows RT", not entirely at least)
norfanin
SetupWindowData in SDL_windowswindow.c doesn't initialize two members of SDL_WindowData with NULL. This is an issue because other parts of the SDL code seem to make the assumption that this is the case. WIN_DestroyWindowFramebuffer for example uses data->mdc and data->hbm if they're not NULL.
Added a reference to SDL_Direct3D9GetAdapterIndex to SDL_test_common.c so SDL will fail to compile if the new symbol isn't included properly.
CR: Jorgen
aBothe
I tried to experiment a bit with SDL2 and OpenGL today and noticed that something caused some weird flickering when resizing my nicely drawn SDL2/OpenGL window:
Just after resizing, the background went black and I had to let my OpenGL code redraw the contents..
However, after some hours spent with googling I found out that in OpenGL examples where this CWBackPixel flag was not used when creating X windows, there was no flickering while resizing the window.
See http://www.sbin.org/doc/Xlib/chapt_04.html @ "The Window Background" for more info.
# Date 1379621782 -3600
# Thu Sep 19 21:16:22 2013 +0100
Work around a false-positive in the X11 mouse wheel code
This false positive occurs when one particular button on my mouse is
pressed. The kernel which I'm using is patched to cause a release event to
be synthesised immediately when the mouse says that this button is pressed
because the mouse doesn't signal release until the button is next pressed.
(Also documents a false negative, observed with the horizontal scroll wheel
on the same mouse.)
X11_RestoreWindow() had a call ordering problem that prevented activation, and X11_RaiseWindow() wasn't attempting activation. Windows and OS X both activate in these cases.
CR: saml
SDL provides an SDL_VIDEO_X11_VISUALID environment variable that lets you override
window visuals, but it wasn't being checked for OpenGL windows.
CR: Sam.
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
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.
Ryan C. Gordon
Sam Lantinga
Gabriel Jacobo
J?rgen P. Tjern?
Philipp Wiesemann
David Ludwig
Edward Rudd
pgriffais