Pelya,

What an excellent job you really did for us!
I think many games based on SDL library could be successfully ported onto Android.
BTW, is it possible to solve the issue that AP will crash after switching to other Apps then back?
Or it's an unknown issue? (maybe no way to solve?)

Peace

Draffodx wrote:

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

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

No, the audio is routed through Java code - you can't do it other way on Android. If you want to access native layer, like ALSA drivers, you'll have to put your application inside Android firmware image, and re-flash your phone (obviously not suitable for Android Market).
I've tried once to access video using Linux framebuffer device, my application was working but after closing it the phone was totally unusable.

BTW, is it possible to solve the issue that AP will crash after switching to other Apps then back?
Or it's an unknown issue? (maybe no way to solve?)

Yes it's possible, however I don't have much time currently to fix that, sorry. Maybe I'll do some more development in a month or two.

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 ?

I'm planning to move to SDL 1.3, it already supports all OpenGL-ES stuff that I need to implement into SDL 1.2 manually.
Or maybe shagrath78 or hqhe1982 will release a proper SDL 1.3 port without nasty bugs, would be awesome I'll change the link in the first post and give you a credit .

Edit: I've discovered that someone already ported Quake 3 onto Android: http://code.google.com/p/kwaak3/ , seems that it has that bug with recreating OpenGL contexts fixed.

Edit2: Fixed libtremor compilation flags for endianness, if you are using OGG files please redownload my sources from github.

This is an excellent porting, and the author must have solved a lot of difficult problems when arriving current stage.

I have a question when try compiling and runing alienblaster under a emulator.

1. enviroment
Android SDK r5, API-level 7
NDKr3
2. The compilation is successful, without any problem.
3. However, there is a problem when running it, below are logcat output, and the most interesting messages are set bold

05-12 08:59:39.093: DEBUG/SensorManager(232): found sensor: Goldfish 3-axis Accelerometer, handle=0
... ...
05-12 08:59:40.463: INFO/ARMAssembler(232): generated scanline__00000077:03010144_00001004_00000000 [ 43 ipp] (83 ins) at [0x2ea480:0x2ea5cc] in 4926566 ns
05-12 08:59:40.495: INFO/ARMAssembler(232): generated scanline__00000077:03010104_00001A04_00000000 [ 23 ipp] (46 ins) at [0x2eadd8:0x2eae90] in 712952 ns
05-12 08:59:40.505: INFO/DemoRenderer(232): onDrawFrame complete
05-12 08:59:40.524: INFO/DemoRenderer(232): onDrawFrame complete
05-12 08:59:40.565: INFO/DemoRenderer(232): onDrawFrame complete
05-12 08:59:41.145: DEBUG/Zygote(30): Process 232 exited cleanly (1)
05-12 08:59:41.155: INFO/WindowManager(53): WIN DEATH: Window{43d9a3a8 SurfaceView paused=false}
05-12 08:59:41.165: INFO/WindowManager(53): WIN DEATH: Window{43d98f00 de.schwardtnet.alienblaster/de.schwardtnet.alienblaster.DemoActivity paused=false}
05-12 08:59:41.165: INFO/ActivityManager(53): Process de.schwardtnet.alienblaster (pid 232) has died.
05-12 08:59:41.204: INFO/UsageStats(53): Unexpected resume of com.android.launcher while already resumed in de.schwardtnet.alienblaster
05-12 08:59:41.294: WARN/InputManagerService(53): Got RemoteException sending setActive(false) notification to pid 232 uid 10027


4. I can not tell which part is wrong.
So my question is, is there a way to make the program run under emulator?
Or shall I recompile and run the program with SDK 1.6(API-level 4) since its README stated that it should be done with 1.6?

whogiawho wrote:3. However, there is a problem when running it, below are logcat output, and the most interesting messages are set bold

Recently I've messed up with sources a bit - I've splitted the single statically-linked lib into separate shared libraries, so you can release your closed-source app without violating LGPL license of libSDL.
And of course it broke application in the most unexpected place - I've fixed that already, redownload sources please (however there is a lot of debugging spam left, I'll remove it tomorrow).

There are still some problems with the new version 94df8e2 on my running env.
Here are the logs. Maybe it is not stable.
However it is a great job that u seperated the static libs from the program.
Is there a stable version(even the static lib one) that I can run without a problem?

05-13 09:29:16.112: VERBOSE/alienblaster(217): Game::Game() 0
05-13 09:29:16.170: INFO/libSDL(217): FlipHWSurface: Frame is ready to render
05-13 09:29:16.170: ERROR/libSDL(217): FlipHWSurface: called before SetVideoMode
05-13 09:29:16.170: INFO/libSDL(217): SDL_SetVideoMode(): application requested mode 320x480
05-13 09:29:16.352: INFO/libSDL(217): FlipHWSurface: Frame is ready to render
05-13 09:29:16.692: INFO/ARMAssembler(217): generated scanline__00000077:03010144_00001004_00000000 [ 43 ipp] (83 ins) at [0x2ea480:0x2ea5cc] in 2676323 ns
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: Frame rendering done
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: exit
05-13 09:29:16.790: INFO/libSDL(217): SDL_SetVideoMode(): done
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: Frame is ready to render
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: Frame rendering done
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: exit
05-13 09:29:16.790: INFO/libSDL(217): FlipHWSurface: Frame is ready to render
05-13 09:29:16.790: INFO/ARMAssembler(217): generated scanline__00000077:03010104_00001A04_00000000 [ 23 ipp] (46 ins) at [0x2ea5d0:0x2ea688] in 599692 ns
05-13 09:29:16.790: INFO/libSDL(217): nativeRender: Frame rendered
05-13 09:29:16.822: INFO/libSDL(217): FlipHWSurface: Frame rendering done
05-13 09:29:16.822: INFO/libSDL(217): FlipHWSurface: exit
05-13 09:29:16.822: VERBOSE/alienblaster(217): Game::Game() 1
05-13 09:29:16.822: VERBOSE/alienblaster(217): Settings::Settings() 0
05-13 09:29:16.822: ERROR/Alien Blaster(217): Cannot load image ./images/alienblasterintro.bmp

If I have some background knowledge of how u make SDL cooperated well with the SurfaceFlinger, the bug may be fixed by me.

However, it is the first time I entered this field. And it may take me some time to digest what the code does.

For example, if we want to draw something of openGL in java code, we called gl.drawElements.
But what alienblaster did now is to delegate such kind of drawing job to nativeRender. How does this task be achieved with SDL porting?
That is a very interesting question for me now.

That's strange that you cannot run the game inside emulator, I've tested it yesterday and it was working.
Seems that the application failed to download some data files from internet, try to uninstall and reinstall it (it should write at the first run "Downloading file XXXXX, saving file YYYYY" etc).

whogiawho wrote:For example, if we want to draw something of openGL in java code, we called gl.drawElements.
But what alienblaster did now is to delegate such kind of drawing job to nativeRender. How does this task be achieved with SDL porting?
That is a very interesting question for me now.

It is a bit tricky - when the GLSurfaceView.Renderer.onDrawFrame() is called from Java it locks until C code renders the frame to in-memory surface and calles SDL_Flip(). Inside SDL_Flip() there is a code which copies in-memory surface to a screen, and then locks itself and unlocks Java code. onDrawFrame() finishes and next onDrawFrame() is called - then C code unlocks and exits from SDL_Flip() to render next frame.

I've added some OpenGL handling to libSDL, and added GLXgears example - sadly it doesn't output anything to screen (however the same code compiled for Linux works), this requires more debugging.
Edit: I've replaced SanAngeles demo app source with GLXgears, and it works on Android, so that's my buggy libSDL implementation prevents it from working okay.
Edit2: I've found the problem - the OpenGL calls were done from main() thread, not from the Java rendering callback. I already figured out a hack which fixes that (just launch main() from Java rendering callback, and it will never return, hehe), it will require some code redesign and some time though.

pelya wrote:That's strange that you cannot run the game inside emulator, I've tested it yesterday and it was working.
Seems that the application failed to download some data files from internet, try to uninstall and reinstall it (it should write at the first run "Downloading file XXXXX, saving file YYYYY" etc).

It can be run now on emulator, that is, the menu interface can be displayed and UP/Down keys can work. But it is based on setting DownLoadToSDcard to false.
That scenario of Setting DowLoadTo SDcard to true is not working, and that is why I can got error messages some days ago.

pelya wrote: It is a bit tricky - when the GLSurfaceView.Renderer.onDrawFrame() is called from Java it locks until C code renders the frame to in-memory surface and calles SDL_Flip(). Inside SDL_Flip() there is a code which copies in-memory surface to a screen, and then locks itself and unlocks Java code. onDrawFrame() finishes and next onDrawFrame() is called - then C code unlocks and exits from SDL_Flip() to render next frame.

That is really tricky. More codes need to be read to get a full understanding. How smart u are to come up with this idea to make SDL work well with SurfaceFlinger!

pelya wrote:I've added some OpenGL handling to libSDL, and added GLXgears example - sadly it doesn't output anything to screen (however the same code compiled for Linux works), this requires more debugging.
Edit: I've replaced SanAngeles demo app source with GLXgears, and it works on Android, so that's my buggy libSDL implementation prevents it from working okay.
Edit2: I've found the problem - the OpenGL calls were done from main() thread, not from the Java rendering callback. I already figured out a hack which fixes that (just launch main() from Java rendering callback, and it will never return, hehe), it will require some code redesign and some time though.

Obviously u are still doing some other interesting stuffs besides the above porting SDL to android. Good luck!!

The OpenGL mode is working now - I've put GLXgears example in repository - remove files under project/jni/application/src and copy there glxgears.c to test.
Next step will be hardware accelerated SDL surfaces.
Also there is tiny performance improvement because video rendering is done in a single thread now, without mutexes and thread switching (I wonder if I can do the same thing for audio).
Edit: tested with SD card on emulator, it works okay.

Thank you for your effort on putting SDL on android, i started a Supertux porting so i rely very much on your experties

- Cheers

Some news: I've moved to SDL 1.3 - hardware-accelerated surfaces are now supported (though colors on GLXGears demo are screwed up).
Also accelerometer acts like arrow keys - it may be not convenient for devices which have keyboard, but I cannot test anything on my keyboard-less device without it.

I've just tried your new port, but now the screen is not scaled as it was previously, are you going to fix that?

I'm using an 640x480 res. in SDL on a 480x320 screen...

oNaiPs wrote:I've just tried your new port, but now the screen is not scaled as it was previously, are you going to fix that?

I'm using an 640x480 res. in SDL on a 480x320 screen...

I'll add screen scaling back in few weeks. Well, at least now it renders fast.

pelya wrote:

oNaiPs wrote:I've just tried your new port, but now the screen is not scaled as it was previously, are you going to fix that?

I'm using an 640x480 res. in SDL on a 480x320 screen...

I'll add screen scaling back in few weeks. Well, at least now it renders fast.

I've added automatic screen scaling, for some reason it works only in vertical screen orientation, I'm fixing that.

Edit: I've added new setting to disable Z-Buffer for 2-D games, and optimized audio. Horizontal screen orientation still fails. Also I've discovered that my application won't run anymore on ADP1 because it runs out of memory. Furthermore, GLXGears example works but outputs nothing to screen, so currently my port is broken for Android 1.6 platform, but working on Android 2.1.

Edit2: finally solved horizontal screen orientation + resizing

hi pelya:
sorry for my poor English.
it is a great work!
i downloaded your latest project today,it works on android 1.6,2.0 fine,but on 2.01,2.1 crashed.why ?