Hi,

I'm also following your work with quite some interest. I've ported Wormux to android, using your ports of sdl mainly, but also sdl_mixer/sdl_image & co.

Unfortunately, Wormux uses SDL1.2 (1.3 having lingered for years is a bit disheartening) so I'm not beneficing from your code changes since mid-May. And seeing the performance of Wormux on my Samsung Spica (which I know is a low-end armv6 CPU with low GL performance and 480x320 screen) limited at 11fps shows that it needs every bit of improvement...

Wormux uses RGBA (yet in display format with or without alpha), maybe that's why it is so limited.

Anyway, thanks a lot for making this possible!

There is GSOC student working on official SDL 1.3 port for Android, and I'm thinking of reverting to more widely-used SDL-1.2, and adding HW acceleration by copypasting wonderful OpenGL ES renderer from SDL 1.3.
BTW the existing HW accelerated SDL 1.2 code will NOT be automatically HW accelerated after switching to SDL 1.3 - you have to replace every "SDL_Surface" with "SDL_Texture", was kinda disappointing to me. However every other thing is converted okay through compatibility layer (except for keyboard - all keycodes are different now).
However I won't start that 'till I fix crashing on Andoird 1.6 .

BTW why are you thinking 11 FPS is slow for some damn cellphone?

Actually it's good, but it means that our game is way too heavy and requires much work to be actually playable. It's not about the phone but rather the game. And anyway my phone is known to have bugged gl drivers.

btw, have you ever tried the fb console sdl 1.2 driver that some have reported to work?

kurosu wrote:btw, have you ever tried the fb console sdl 1.2 driver that some have reported to work?

Yup, tried that. It requires root access to your phone, to open /dev/graphics/fb0 device, which application installed from market cannot achieve, and it leaves phone screen unusable after application exits - you have to reboot by unplugging battery.
The whole idea of my port was to provide framework to release your apps on Google market, no matter if it will be slower than pure native code because of Java-to-C wrappers.

Edit: some news: now it's working on 1.6 now and crashes on 2.1, fascinating, isn't it? However GLXGears demo works everywhere.

I've realized that i can do hardware scaling with glorthof, maybe it's better to use this way other than pixel manipulating...

this project looks very intersting, Android is in dire need for a good 2d gfx lib.

oNaiPs wrote:I've realized that i can do hardware scaling with glorthof, maybe it's better to use this way other than pixel manipulating...

That will work if you're doing OpenGL-only stuff, and using SDL instead of GLX to create window and OpenGL context.
You can do the same using only SDL 1.3 functions - you're creating HW accelerated texture using SDL_CreateTextureFromSurface() (or SDL_CreateTexture()/SDL_QueryTexturePixels()) - it is direclty mapped to OpenGL texture.
Then the OpenGL ES inside SDL renderer draws that texture using glDrawTexiOES(), which resizes it as needed using video hardware (theoritically, Alien Blaster still uses SDL 1.2 compatibility mode and renders everything into in-memory surface, so I cannot tell you the actual number of FPS increase).

Jug6ernaut wrote:this project looks very intersting, Android is in dire need for a good 2d gfx lib.

This is good C/C++ - based 2d gfx lib (because there are lot of good C/C++ games that can be easily ported to Android, that was the objective of this project), you can find some nice Java game-oriented libraries here on anddev.org. Unfortunately it's not yet ready for production, but I expect to finish it in three-four months (at least fix all the bugs).

I'm seeing strange things with your port of SDL 1.2 (ie your tree on 2010-05-20) and flags SDL_DOUBLEBUF|SDL_HWSURFACE|SDL_HWACCEL:
- in 16bits mode, SDL_Flip is acting very weirdly: it seems the flip is actually not done
- in all case, I have a strange output to stderr (I redirect it); it seems related to OpenGL stuff:
Attrib 0 (Vertex) -> loc 0
Attrib 1 (Color) -> loc 1
Attrib 2 (Normal) -> loc 2
Attrib 3 (MultiTexCoord0) -> loc 3
Attrib 4 (MultiTexCoord1) -> loc -1
Attrib 5 (PointSize) -> loc -1
Attrib 6 (MatrixIndices) -> loc -1
Attrib 7 (Weights) -> loc -1

index = 226

There is no string "Attrib" in SDL sources - this message should be coming from your OpenGL drivers.
Cannot say anything about flip - I did not check SDL 1.2 branch for a long time. Does it run on emulator?
Posting link to your sources may greatly help (though I don't promise I'll look into it right away, I don't have much time lately)

pelya wrote:There is no string "Attrib" in SDL sources - this message should be coming from your OpenGL drivers.

You're surely right, it might be even a bug/sloppy code in the driver. Doesn't seem to cause me any harm, so I reported it only in case it meant something to you.

Cannot say anything about flip - I did not check SDL 1.2 branch for a long time. Does it run on emulator?

As for the emulator, it also displayed the flickering but I haven't tried it, due to its low speed and my inability to get it to properly handle debug sessions. I will retry again to see what it reports.

16bits video mode is mostly here to save memory. Internally we use as close to the 32bits display format (if possible, otherwise, plain ARGB), because of the per-pixel alpha blending.

Posting link to your sources may greatly help (though I don't promise I'll look into it right away, I don't have much time lately)

That's be the troublesome part: not all changes have been merged yet, and the devil lies in the details.
Besides, directing you to:
http://svn.gna.org/viewcvs/wormux/trunk/src/
won't help you much. Some bits of the code for initialization and general operation is sprinkled over:
http://svn.gna.org/viewcvs/wormux/trunk ... iew=markup
http://svn.gna.org/viewcvs/wormux/trunk ... iew=markup
but that's too heavy a code base for you to spend time on it, I believe.

Thanks for the reply!

Btw, there is a GSoC for the android port:
http://forums.libsdl.org/viewtopic.php?t=6243
http://hg.libsdl.org/SDL-gsoc2010_android/

They are focusing on SDL 1.3 (I expected that, too bad they prefer dropping SDL1.2, which is the only officially available in many Linux distributions).

kurosu wrote:Btw, there is a GSoC for the android port:
http://forums.libsdl.org/viewtopic.php?t=6243
http://hg.libsdl.org/SDL-gsoc2010_android/

They are focusing on SDL 1.3 (I expected that, too bad they prefer dropping SDL1.2, which is the only officially available in many Linux distributions).

Yeah, that port currently has video and nothing else.

There is another more-less complete SDL 1.2 port by Mamaich and some description in English, it's main difference is that it does not use Android build system but own ARM toolchain, so you don't need to edit Android.mk but use common "./configure --host=arm-eabi- && make" approach. It does not have HW acceleration either, so it's pretty much like my SDL 1.2 branch.

pelya wrote:There is another more-less complete SDL 1.2 port by Mamaich and some description in English

Someone is actually porting scummvm to android, but they are linking against the (normally unavailable) internal libraries, like skia and pixelflinger.

As for the approach used in the port you describe, I'm still uncertain. I've just tested your SDL 1.3 branch, and unfortunately, SDL_DisplayFormat* functions seem to force h/w textures (despite my requesting s/w ones), which doesn't sit well with the fact we want read access to some of those surfaces. Once I worked around this, I finally was able to see a dismal performance: framerate was likely halved compared to 1.2. Maybe this underlines some necessary adaptations, but for now I'll stay with 1.2 then.

I've looked up at your code for handling double-buffering in SDL 1.2, and don't see any reason for it to fail, so the problem is probably in the wormux code.

kurosu wrote:

pelya wrote:There is another more-less complete SDL 1.2 port by Mamaich and some description in English

Someone is actually porting scummvm to android, but they are linking against the (normally unavailable) internal libraries, like skia and pixelflinger.

As for the approach used in the port you describe, I'm still uncertain. I've just tested your SDL 1.3 branch, and unfortunately, SDL_DisplayFormat* functions seem to force h/w textures (despite my requesting s/w ones), which doesn't sit well with the fact we want read access to some of those surfaces. Once I worked around this, I finally was able to see a dismal performance: framerate was likely halved compared to 1.2. Maybe this underlines some necessary adaptations, but for now I'll stay with 1.2 then.

I've looked up at your code for handling double-buffering in SDL 1.2, and don't see any reason for it to fail, so the problem is probably in the wormux code.

Well, it was designed to generate only h/w textures, if you don't like h/w accel or doing per-pixel access you should use old SDL_Surface api instead of SDL_Texture. Actually there is small part of code in SDL_renderer_gles.c:839 which does one extra memcpy() on the whole screen before rendering, that's why it's even slower than SDL 1.2. But if you don't use ANY pixel-access operations it should be faster. Well, if you're updating not the whole screen, but part of it, or some texture to blit on it, you may call SDL_DirtyTexture() or SDL_LockTexture() with dirty flag - it will then update only small rectangle of texture, not the whole texture.

Also there are some news - I've found out that latest trunk crashes on Android 2.0+ inside audio code, if you'll disable audio it will work okay. And yet it works on Android 1.6 for some reason, I guess I'll have to dig into AudioTrack and PixelFlinger source (or revert to my slower but working implementation with two threads).

Edit: if you need to render surfaces with alpha channel or colorkey there are RGBA4444 and RGBA5551 (1 bit alpha for colorkey) pixel formats available in OpenGL ES, the color range is of course worse than RGB565 but hey, you have H/W accelerated alpha, no need to do any pixel-access. Alien Blaster also uses images with color key and alpha, the only thing that it lacks is proper use of SDL 1.3 SDL_Texture features (or proper SDL 1.2 port, I'm still working on it )

Edit2: more news: I've fixed the crashing in current trunk, now I'll be moving it back to SDL 1.2.

With some hacks I've forced Alien Blaster to use HW acceleration (gogo download .apk from link in the first post), it gives me fascinating 45 FPS on my ADP1, however some textures are drawn out of place. Also I've discovered that OpenGL ES cannot load textures wider than 1024 pixels, so I've had to split in-game font image to several smaller ones.
After I'll fix accelerometer and define some game controls for keyboard-less HTC Evo the game is ready to be published on Android Market (I guess I'll have to spend those 25 bucks for Google developer account anyway ).