This is the port of SDL to Android - includes SDL 1.2 and SDL 1.3, SDL_mixer, SDL_image and bunch of other libs. Both SDL 1.2 and 1.3 have hardware acceleration, you may also use OpenGL ES with SDL. Several games are included as working examples.

The libsdl.org now has an official SDL 1.3 Android port, which is more recent and better suited for creating new applications from scratch, this port is focused mainly on SDL 1.2 and compiling existing applications, it's up to you to decide which port is better.
Also this port is developed very slowly, although the same is true for an official port.

It is intended to be used to easily port your own C++ applications that use SDL library,
readme file describes all the steps required. No Java knowledge is necessary to use this lib.

The minimal requirement to run this lib is Android 1.6. Android 1.5 devices do not have OpenGL lib
C++ RTTI and exceptions are also supported, with the official toolchain.

Bunch of compatibility settings is implemented:

• Commonly used video modes (320x240, 640x480 etc) - they will automatically stretch to the whole screen, however 640x480 in SW is slow.
• On-screen keyboard is available with arrow keys + 6 configurable buttons, transparent to the application. You may submit your own keyboard theme if you have some designer talent. Full-text on-screen QWERTY input is also available, toggled with special 7-th button.
• Two-button mouse emulation, via multitouch event or screen pressure, if device supports that.
• Accelerometer as arrow keys or joystick
• Trackball support

You can combine SDL and OpenGL ES, see GLXGears example in sources.

Get the sources from GIT repository (please don't use file releases, they are outdated - grab latest GIT revision).

List of games published to Android Market and compiled .apk files

pelya wrote:libSDL ported to Android (includes SDL 1.2.14, SDL_mixer 1.2.11, Tremor and STLPort).
Unlike other libSDL ports around, it does not require root access to video device, and will produce .apk package that you may publish (and sell) on Android Market.

This interests me greatly as I would love to port MPlayer and use that instead of android's rather limited video player. I see that it seems to be based on http://gitorious.org/0xdroid/external_libsdl-12 , which also seems to have libalsa and esd ports.

atomicdryad wrote:

pelya wrote:libSDL ported to Android (includes SDL 1.2.14, SDL_mixer 1.2.11, Tremor and STLPort).
Unlike other libSDL ports around, it does not require root access to video device, and will produce .apk package that you may publish (and sell) on Android Market.

This interests me greatly as I would love to port MPlayer and use that instead of android's rather limited video player. I see that it seems to be based on http://gitorious.org/0xdroid/external_libsdl-12 , which also seems to have libalsa and esd ports.

No it's not based on anything, if I'd knew someone already did some port I would tried to reuse that.
Also I should've used libsdl 1.3, because it already have GLES code I've used for drawing, and it supports hardware surfaces unlike mine.
I doubt about libalsa, because that would mean you have to install your own custom kernel on your device, and that's possible only for unlocked devices. The "correct way" sound should be implemented is by using AudioTrack Java class and providing some callbacks from C code which will feed it with data.

Seems that anddev.org won's allow anonymous file download, so here's the code repository:
http://github.com/pelya/commandergenius ... dl_android
If I'll ever implement sound support it will go there.

thank you very much ! I'll play with it and try to look what I can do to help for sound support
Actually I started 2 weeks ago a port of SDL1.3 with some hooks into my own GLSurfaceView implementation, from java-side. Right now I only got the spinning cube sample working (the trunk/SDL/test/testgles.c file).
It's very hacky and obviously done in the wrong way cause I'm a big newbie at SDL. (I don't really get how to mix SDL 2D routines and 3D together)

On a side note, I don't know If you have to manage the GL thread in the Java app, I didn't, and even if it's not recommended by the Android team, I guess this is the way to go for a proper SDL compatibility ?

shagrath78 wrote:On a side note, I don't know If you have to manage the GL thread in the Java app, I didn't, and even if it's not recommended by the Android team, I guess this is the way to go for a proper SDL compatibility ?

Look indo 'libsdl/src/video/android", the code is rather small (but bit messy)
In my code the Java thread that draws OpenGL calls C callback inside libSDL, which then waits until other C threads of your app draw onto the SDL "Main Video" surface (which is actually just malloc()-ed memory region), and call SDL_Flip(). Then in SDL_Flip() the pointer to Main Video surface replaced with another memory region, and OpenGL thread unlocks and copies the data from prev mem region into GL texture.
It should also work without double-buffering (not tested by me), but your code then will block in SDL_Flip() until GL thread finishes it's work. Android have only one CPU anyway, so speed should be the same.

OpenGL in SDL is also possible, but then your code should block in SDL_GL_Flip() until Java GL thread signals you that it's ready. I did not implement that, and don't have much time lately. Maybe in a few weeks...

Edit: finally got my hands on HTC dev phone, the game is playable with few fixes - you may get them here. Still no sound, sorry.

Got audio working, yay!
You may check it out here

It's working, amazing ! I had to comment the audio logs though, my logcat console was getting killed :p
It's still a little laggy, I don't know how much cpu power that game requires

Anyway It's a great work, congrats ! You should post your work on the android-ndk group ! sure some people would help

About the OpenGL implementation in SDL1.3, like I said I'm a beginner
I did not mess with SDL_Flip and other functions, I just made a bridge with the egl functions in Java (getcontext, swapbuffers, etc.) as they're not available in the NDK and changed the generic SDL opengl renderer

I've removed that logging, and added downloading application data from internet on the first run, so the libSDL port is complete (also updated first post).

Here is the .apk file for you to test for performance

Would be nice if someone fixed GUI elements in that game out of place, added parallax to game field (the game field is 640x480 actually, and you cannot see right part of screen), added mouse (touchscreen) support, and released it on Android market for no price .

I am porting sdl-1.3 to android,
The audio and video subsystem can work well.
I will put some demos to this site.

sdl-1.3 android port:
the mouse and keyboard subsystem can also work well.

now i has a problem.
when the android app hide and then show again,
opengl surface must recreate, but i can't find a method to do it.

It was essentially the major issue I got when I tested my SDL 1.3 port. Samples were working but the loss of the GL context and surface when onPause() is triggered is a pain in the ass. There's obviously something to do but the amount of trickery required is not really fun.
Another way would be to reuse the full GLSurfaceView class but I don't know how to share the EGL context with my own rendering thread without break everything

To shagrath78:

Sorry, My english is so poor.

Your problem is the same as my's:
OPENGL-ES surface and context must be recreated after android app hide and reshow.

I think maybe that is a method, but i do not test it.
Calling eglMakeCurrent() and eglDestroySurface() to destroy EGL surface before android app hide,
and calling eglMakeCurrent() and eglCreateWindowSurface() to recreate EGL surface after android app reshow.

Hello
i would like to port a game done using sdl/opengl on android,
i read this topic and it looks like some of you guys already ported sdl 1/3 with ES support ?? how can i use this ported lib ?
Thanks a lot for this job,

mine is incomplete and unstable, you don't want to use that

pelya wrote:Got audio working, yay!
You may check it out here

By that do you mean your accessing Audio at the native layer?