Sat, 12 Aug 2017 15:00:33 -0700Fixed bug 3208 - Minor improvements to the configure script
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 15:00:33 -0700] rev 11245
Fixed bug 3208 - Minor improvements to the configure script

Rafal Muzylo

"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)

Sat, 12 Aug 2017 13:05:26 -0700Note that texture contents are undefined when the texture is created.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 13:05:26 -0700] rev 11244
Note that texture contents are undefined when the texture is created.

Sat, 12 Aug 2017 12:59:22 -0700Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:59:22 -0700] rev 11243
Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0

Simon Hug

The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.

The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.

Sat, 12 Aug 2017 12:56:28 -0700Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:56:28 -0700] rev 11242
Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.

Sat, 03 Jun 2017 09:13:08 +0200prefer virtual keycodes over scancodes for extended keys
ouned <michael@losert.org> [Sat, 03 Jun 2017 09:13:08 +0200] rev 11241
prefer virtual keycodes over scancodes for extended keys

Sat, 12 Aug 2017 12:34:09 -0700Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:34:09 -0700] rev 11240
Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events

Adam M.

The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".

For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.

If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).

You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.

Not only is it inconsistent with itself, I think it makes keyboard processing harder.

The problem is near line 740 in SDL_keyboard.c:

if (SDL_KEYDOWN == type) {
modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
switch (keycode) {
case SDLK_NUMLOCKCLEAR:
keyboard->modstate ^= KMOD_NUM;
break;
case SDLK_CAPSLOCK:
keyboard->modstate ^= KMOD_CAPS;
break;
default:
keyboard->modstate |= modifier;
break;
}
} else {
keyboard->modstate &= ~modifier;
modstate = keyboard->modstate;
}

In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.

Sat, 12 Aug 2017 12:24:59 -0700Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 12:24:59 -0700] rev 11239
Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.

owen

I removed all the static variables from SDLActivity.java

Updated all the SDL_android.c jni calls as well

I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);

This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.

Sat, 12 Aug 2017 08:15:09 -0700Fixed bug 3191 - haptic system on android?
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 08:15:09 -0700] rev 11238
Fixed bug 3191 - haptic system on android?

Patch provided by jintiao and Milan Nikolic, thanks!

Sat, 12 Aug 2017 08:06:16 -0700Fixed part of bug 3227 - patch for multiple buttons at the same time not working
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 08:06:16 -0700] rev 11237
Fixed part of bug 3227 - patch for multiple buttons at the same time not working

Philipp Wiesemann

There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.

Sat, 12 Aug 2017 00:04:46 -0700Fixed compiler warnings on Visual Studio 2013
Sam Lantinga <slouken@libsdl.org> [Sat, 12 Aug 2017 00:04:46 -0700] rev 11236
Fixed compiler warnings on Visual Studio 2013