Thanks , I'll integrate that code after a week, after my vacation ends.

I have developed a RTSP stream media player and it use the SDL as the audio and video render layer.
Now I want to port this media player to android platform. My app has multi threads(data receive thread, video decode thread, video surface update thread,etc.) created by SDL_CreateThread.
I have tried the offical SDL1.3 port, but failed! The log info always show:" non-VM thread making JNI calls".
is this SDL port fit for me? or how to solve my problem? Thank you.

along0612 wrote:I have developed a RTSP stream media player and it use the SDL as the audio and video render layer.
Now I want to port this media player to android platform. My app has multi threads(data receive thread, video decode thread, video surface update thread,etc.) created by SDL_CreateThread.
I have tried the offical SDL1.3 port, but failed! The log info always show:" non-VM thread making JNI calls".
is this SDL port fit for me? or how to solve my problem? Thank you.

This problem has troubled me several days! any suggestion is very helpful for me.

You have to make all SDL calls that draw to the screen only from your main thread, with official SDL 1.3 port. My port has a compatibility option for such apps, it's called AppDorsNotCallSdlFlip or something like that in AndroidAppSettings.cfg, but it will render a bit slower then.

pelya wrote:You have to make all SDL calls that draw to the screen only from your main thread, with official SDL 1.3 port. My port has a compatibility option for such apps, it's called AppDorsNotCallSdlFlip or something like that in AndroidAppSettings.cfg, but it will render a bit slower then.

Thank you very much, pelya. your info is very helpful.

Has anyone gotten OpenAL to work? Mine always crashes on device = alcOpenDevice( 0 );

I use SDL auido functions,such as SDL_OpenAudio, SDL_PauseAudio, etc, to play audio pcm data on Windows platform in my app. Normally, the app work fine! But when I start other apps that use audio driver(for example mp3 player), my app will silence except for make my app in current window. How to solve this problem?

Just FYI I rolled back my previous jni/env changes as, actually, it didn't make much sense. If a user wants the JNIEnv pointer, all you really need to do is make a dummy call, like nativeSetEnv(), and store the values in C code. Passing it through SDL_main(), then main(), and using -DRELEASE_BUILD is unnecessary. Whoops!

I've added two functions - SDL_ANDROID_JniEnv() and SDL_ANDROID_JniVideoObject(), just in case someone will miss that, to SDL_screenkeyboard.h (which is my own extension anyway).

Also I've added OpenAL demo app to the project/jni/application/openal-demo, it seems to work without errors.

On Android, when you're opening another application, your app goes to background, and naturally the sound stops. If you don't want that - add following code to your main():

Code: Select all

#include <SDL/SDL.h>
void AndroidDummyBackgroundCallback(void) { /* do nothing */ }
SDL_ANDROID_SetApplicationPutToBackgroundCallback( &AndroidDummyBackgroundCallback, &AndroidDummyBackgroundCallback );


Also I've fixed a bug in my code that prevented SDL running on Nvidia Tegra - based devices, it was introduces a month ago.

Hello,

I started to develop my app prior NDK r5. Thus I used the native code provided in your great port here.

My understanding is that all native things can now be done with NDK r5 and greater.

So my question is:

a) What do I need to do now? Is it recommended to switch to the NDK provided native api?
b) Is it recommended to look at LIBSDL.ORG and download the newest SDL there and start over again?

In the case of b) I dont have he Pelya wrapper anymore. So does the newest Android SDL have a ability to
download data to the device as Pelya has? I mean the zipfile which will be provided to the app on runtime.

Thx
andreas

If NDK you're using is working for you - you don't really need to switch, NDK r4b is good and stable.
SDL 1.3 from libsdl.org does not contain data downloader - you'll need to write one yourself, however with new native C interface in NDK r5 it's relatively easy to extract data from assets.

Both ports are using GLES to render graphics, and very similar code for audio, so they should be equal in speed (I didn't do any measurements though), so I would say - use my port if you got an existing application you want to get running on Android quickly (most existing apps use SDL 1.2), use port from libsdl.org if you're developing something from scratch (they've got a nice mailing list, so you'll probably get all your questions answered).

Oh, and you may always copypaste the downloader from my port, I've put all Java files under commercial-friendly ZLIB license.

Hey there
First of all, thank you pelya for the support on porting my game to android.
As you know, the game I am actually developing is not very CPU intensive, it only need to render some textured quads to the screen.
I am having 500 / 1000 FPS on my desktop computer but I only achieve 7 - 8 on HTC Desire (which is not bad device).
I don't know what to try Is it normal that speed? Is there something I can do to get higher FPSs?
I have tryed to make a "test" that only renders a black screen and an FPS counter and i have only 50 FPS on that.

The best way to measure FPS is to run some other application, like Angry Birds I believe they will run faster than 7 FPS on Desire. The main bottleneck, as far as I know, is the amount of textures that you are drawing - drawing one big texture will be far faster than drawing several small textures, so you should use pre-rendered background if you can. Also you may try to use glDrawTexiOES() function, instead of the usual glDrawArrays() - it is the GLES extension and not available in the usual OpenGL, and it's used to draw texture to screen without rotation or any 3D transformations, it may only stretch or shrink the texture along horizontal/vertical axis, so it should be somewhat faster on most hardware.
Could you please try this demo - it gives 25 FPS on my HTC Evo, with approx. 1000 small textures on the screen - it's using glDrawTexiOES().

that demo gives me 23 - 29 FPS and looks really nice!
Is the source code in the GIT repository? i have to take a look to port my gfx code to use dlDrawTexiOES().

The demo just uses SDL in hardware-accelerated mode, the SDL itself makes use of the DrawTex extension.
Here's the related code in the SDL renderer, here's the official documentation on DrawTex extension (it's hard to read because of the math terms), here's an example
Also glDrawTex draws the images upside-down, because the OpenGL coordinate system starts at the bottom-left of the screen, not at the upper-left, as video memory does, but it's possible to supply negative height to the glTexParameteriv() to flip it to the normal orientation.