Sat, 15 Oct 2016 20:01:30 +0200Removed unused constants in controllermap program.
Philipp Wiesemann <philipp.wiesemann@arcor.de> [Sat, 15 Oct 2016 20:01:30 +0200] rev 10542
Removed unused constants in controllermap program.

Fri, 14 Oct 2016 17:06:28 +0100emscripten: check if device pixel ratio has changed
Csongor Szabo <csongor.szabo@prezi.com> [Fri, 14 Oct 2016 17:06:28 +0100] rev 10541
emscripten: check if device pixel ratio has changed

Fri, 14 Oct 2016 08:56:04 -0700Fixed compiler option warning for 64-bit builds on Visual Studio 2008
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:56:04 -0700] rev 10540
Fixed compiler option warning for 64-bit builds on Visual Studio 2008

Fri, 14 Oct 2016 08:40:21 -0700Fixed bug 3453 - First mouse button input after a drag and drop event is ignored
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:40:21 -0700] rev 10539
Fixed bug 3453 - First mouse button input after a drag and drop event is ignored

Olav Sorensen

After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should.

Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.

Fri, 14 Oct 2016 08:27:44 -0700Fixed bug 3452 - Getting unicode arguments for the main entry point on Windows
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:27:44 -0700] rev 10538
Fixed bug 3452 - Getting unicode arguments for the main entry point on Windows

Simon Hug

There are currently three entry points in the SDL2_main code for windows: main, wmain and WinMain. Only the latter two properly convert the arguments to UTF-8.

Console applications linked with MSVC will always link with the main entry point (wmain has to be selected by manually setting the entry point). This makes it likely that such programs will not have proper unicode arguments.

Fri, 14 Oct 2016 08:22:48 -0700Fixed warning about redefining DECLSPEC
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:22:48 -0700] rev 10537
Fixed warning about redefining DECLSPEC

Fri, 14 Oct 2016 08:20:40 -0700Fixed warning about missing field initializers in SDL_DBusContext
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:20:40 -0700] rev 10536
Fixed warning about missing field initializers in SDL_DBusContext
Static variables are automatically initialized to zero.

Fri, 14 Oct 2016 08:15:39 -0700Fixed processing mouse and keyboard events in hatari, which uses the old SDLMain.m without creating an SDLApplication instance
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 08:15:39 -0700] rev 10535
Fixed processing mouse and keyboard events in hatari, which uses the old SDLMain.m without creating an SDLApplication instance

Fri, 14 Oct 2016 06:57:55 -0700Fixed bug 2758 - Android issues with NDK r10c and API-21
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 06:57:55 -0700] rev 10534
Fixed bug 2758 - Android issues with NDK r10c and API-21

Sylvain

After a long time, I found out more clearly what was going wrong.

The native libraries should be built with a "APP_PLATFORM" as low as possible.
Ideally, APP_PLATFORM should be equals to the minSdkVersion of the AndroidManifest.xml
So that the application never runs on a lower APP_PLATFORM than it has been built for.

An additional good patch would be to write explicitly in "jni/Application.mk": APP_PLATFORM=android-10

(If no APP_PLATFORM is set, the "targetSdkVersion" of the AndroidManifest.xml is applied as an APP_PLATFORM to the native libraries. And currently, this is bad, because targetSdkVersion is 12, whereas minSdkLevel is 10.
And in fact, there is a warning from ndk: "Android NDK: WARNING: APP_PLATFORM android-12 is larger than android:minSdkVersion 10 in ./AndroidManifest.xml".)


to precise what happened in the initial reported test-case:
Let say the "c" code contains a call to "srand()".

with APP_PLATFORM=android-21, libSDL2.so contains a undef reference to "srand()".
with APP_PLATFORM=android-10, libSDL2.so contains a undef reference to "srand48()".

but srand() is missing on devices with APP_PLATFORM=android-10 (it was in fact replaced by srand48()).
So, if you build for android-21 (where srand() is available), you will really have a call to "srand()" and it will fail on android-10.
That was the issue. The path tried to fix this by in fact always calling srand48().


SDL patches that were applied are beneficial anyway, there are implicitly allowing they backward compatibility of using android-21 on a android-10 platform.
It can be helpful in case you want to target a higher APP_PLATFORM than minSdkVersion to have potentially access to more functions.
Eg you want to have access to GLES3 functions (or other) of "android-21". But, if dlopen() fails (on android-10), you do a fall-back to GLES2.

Fri, 14 Oct 2016 01:04:21 -0700Fixed building with cmake when fcitx isn't installed
Sam Lantinga <slouken@libsdl.org> [Fri, 14 Oct 2016 01:04:21 -0700] rev 10533
Fixed building with cmake when fcitx isn't installed