Ryan C. Gordon
To keep the directory layout sane, we should probably move this one piece of source to the linux catch-all directory, instead of making it look like this is part of an SDL "input" subsystem.
--HG--
rename : src/input/evdev/SDL_evdev.c => src/core/linux/SDL_evdev.c
rename : src/input/evdev/SDL_evdev.h => src/core/linux/SDL_evdev.h
Thanks to Denis Bernard!
Also, changed the Android manifest so the app doesn't quit with orientation
changes, and made testgles.c exit properly on Android.
This bumps the build SDK level to 12 (up from 10). Runtime requirements remain
the same (at API level < 12 joystick support is disabled).
Also enables building SDL for armv7 and x86.
Jānis Rūcis
Brief history:
We recently ported a game from SDL 1.2 to SDL 2. While doing Windows testing, I soon discovered that the game exits without opening a window with my cross-compiled SDL2.dll, but works great with the SDL2.dll from the MinGW SDK on libsdl.org. It was as simple as swapping out the DLLs to make it work.
Running the game in Wine showed that the game actually does run, up until the call to SDL_CreateWindow, which fails and leads the game to print out an error:
Failure to create window (LoadLibrary("OPENGL32.DLL"): (null))
Which basically says that there was no error, but maybe that's a Wine quirk.
The error string originates in SDL_windowsopengl.c, in WIN_GL_LoadLibrary, which contains this piece of code:
wpath = WIN_UTF8ToString(path);
_this->gl_config.dll_handle = LoadLibrary(wpath);
SDL_free(wpath);
if (!_this->gl_config.dll_handle) {
char message[1024];
SDL_snprintf(message, SDL_arraysize(message), "LoadLibrary(\"%s\")",
path);
return WIN_SetError(message);
}
After some digging, I discovered the culprit: WIN_UTF8ToString returns NULL. Why? Because it calls iconv_open from an iconv.dll that does not support the UCS-2-INTERNAL encoding. Why does the official SDL2.dll work? Because it calls no external iconv functions at all.
It turns out that the Fedora MinGW infrastructure (from which I obtained the conventiently prebuilt iconv.dll) does not provide a DLL from libiconv, but instead provides a DLL from a minimal Windows library called win-iconv. Which knows a good bit, but doesn't know anything about UCS-2-INTERNAL:
http://code.google.com/p/win-iconv/source/browse/trunk/win_iconv.c#155
So there are two problems here:
1) The error message is clearly useless, because LoadLibrary is an innocent bystander. Instead wpath should probably checked for NULL, and a more appropriate error should be set. Ideally something that makes it clear than an external iconv is causing trouble.
2) SDL doomed itself at the ./configure step, by finding an existing iconv and happily using it without confirming support for the mandatory encodings required by SDL.
There are certainly a few easy ways out of the situation (although I didn't yet manage to figure out how to prevent ./configure from looking for external iconv), but this had me completely stomped for a good while, so I figured it's worth writing down if anything.
(Search also found this, which talks a little about using UTF-16LE instead of UCS-2-INTERNAL: https://bugzilla.libsdl.org/show_bug.cgi?id=2075)
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.
Alexey Petruchik
Although SDL_android.h is not intended to be included by client code sometimes it needed. For example you need JNIEnv pointer to make JNI calls to modified SDLActivity.java (video playback, facebook integration, in-apps). It seems a bit weird to write:
extern "C" {
#include "SDL_android.h"
}
in my AndroidJNI.cpp file.
C++ is a bit of a minefield on Android. Much functionality still doesn't work, and Android can't decide on which C++ standard library to use, so it provides 3 different ones, all of which are incompatible with each other. (It looks like clang is coming too which will add a new compiler and a 4th standard library.)
As middleware, SDL might be distributed as a binary and intermixed with other projects already using C++. If C++ is intermixed in a bad way, bad things will happen. Removing dependencies on C++ will avoid this problem and downstream users won't have to worry/care.
--HG--
rename : src/core/android/SDL_android.cpp => src/core/android/SDL_android.c
rename : src/main/android/SDL_android_main.cpp => src/main/android/SDL_android_main.c
Philipp Wiesemann
SDL_RWFromFile() sets an error to be queried with SDL_GetError() on Android although a valid SDL_RWops pointer is returned.
This happens if the fallback implemented in SDL_android.cpp is used to load compressed assets (see README.android in section "Loading assets") and results in a message like "java.io.FileNotFoundException: This file can not be opened as a file descriptor; it is probably compressed". I think this is confusing and not needed because the loading works as expected.
I attached a patch which changes SDL_android.cpp to not set an error if compressed assets are loaded. In this case also no Exception is queried and no additional string are created.
