SDL for android, once the rather buggy and experimental cousin of SDL for iOS, is now coming along in leaps and bounds. This is great news for developers like me, so let’s check it out! First up though, a handy piece of advice…

How to set your own Android package name

No two applications can have the same package name: not on the same device and not on the market. Unfortunately simply changing the package name in Eclipse (using refactor) will result in a large number of UnsatisfiedLinkError exceptions. This is the fault of the JNI: native functions follow a naming convention which causes the Java package name to be irrevocably hard-coded.

For instance when an instance of the class “org.libsdl.app.SDLActivity” calls the native function “onNativeKeyDown”, we must have defined a C/C++ function called  “Java_org_libsdl_app_SDLActivity_onNativeKeyDown” or we’ll get an exception at run-time.

Aside from being a bit of a mouthful this makes it hard to change the package name to something that uniquely defines your application. Say I want my application to be identified “com.slakgames.biotop”. I can’t, because there’s no function defined called “Java_com_slakgames_biotop_SDLActivity_onNativeKeyDown”. I could just go an change all the function names, but I’d rather not modify SDL’s code if I can help it. That would be sacrilegious.

Luckily Gabriel Jacobo has written a little piece of glue-code which masks the original function names, rather like a typedef. Just remember to include <jni.h> or it won’t compile

Congratulations, you can now publish your application on the market – but wait, we don’t know how to access packaged resources yet…

And now for the main event: SDL-Android goodies galore!

1. SDL now supports accessing APK assets

Up until now all my application resources (images and sound) have been stored in “/sdcard/data/” where they can be accessed without a fuss. Unfortunately to publish on the market it’s necessary to have everything packaged together in a nice tidy apk file. Even if you don’t plan to publish your game on the market not everyone is smart or patient go through the process moving a bunch of data files to the correct folder on their smart-phone. Most would rage-quit before even launching your application!

Access to assets stored in this application package file (which is essentially a zip) is fairly trivial using Java and the Android SDK. Doing things from native code isn’t so simple: your working directory is “/system/“, so actually finding the right apk file isn’t a given, and even if manage to locate it somewhere in the file-system you’ll need some kind of decompression library like zlib if you want to access its contents. All told, not very clean!

Peyla solved the problem by externalising the archive’s contents before launching any native code, in other words saving an uncompressed copy to the sdcard, where it can easily be accessed (fast but still a bit dirty). I’d been thinking along the lines of passing files from Java to C++ via the JNI (slow but clean), but before I could implement either method I found out about RWops (Read-Write operations) or rather SDL_RWops.

This module allows raw data, rather than file-paths, to be used to load application resources and, in the most recent rolling releases of SDL 1.3 (see their Mercurial), has been requisitioned by Tim Angus to allow access files placed in the “assets” directory of the apk as though they are in the working directory. Needless to say this is a big deal: SDL for the win!

2. SDL now supports Android multi-touch

After installing the latest SDL release I found that touch events were no longer working: whereas before the touch-pad generated SDL_MOUSEBUTTONUP, SDL_MOUSEBUTTONDOWN and SDL_MOUSEMOTION events, now there are a set of new events that are generated instead. That’s SDL_FINGERDOWN, SDL_FINGERDOWN and SDL_FINGERMOTION to be precise, and here’s a good example of how they can be used. I believed that multi-touch has been supported for SDL-iOS for some time: nice to see Android get some attention (thanks again to Gabriel Jacobo)

My current project won’t use any multi-touch since in the beginning we didn’t think it would be possible. I’m looking forward to giving it a try for future project though…

3. SDL now supports OpenGLES 2.0

In my post about getting SDL-Android to work I mentioned having to deactivate OpenGLES 2.0 and force the use of OpenGLES 1.1 to avoid getting errors:

libEGL: called unimplemented OpenGL ES API

This bug was documented and has now been fixed, again by Tim Angus The difference between the two versions, from what I understand, is fairly minor for 2D games like “Biotop”: while the first version was geared towards optimised, hardware accelerated graphics, version two concentrates now on 3D graphics, shaders and so on. Still, always nice to have the option

I’m not sure why the site is so slow at the moment but it’s nothing to do with the host. I think WordPress may be playing up. Not much of a Web geek though, I don’t know how to fix it…