oNaiPs wrote:I guess you should change the downloader code, 70% of the times i download the data files from net, the app will crash... maybe if you download first the whole zip file and unzip after...

Fixed that, try to crash it again plz.

I've added back SDL 1.2, now you can select between SDL 1.2 and 1.3 using ChangeAppSettings.sh.
SDL 1.2 has the same software-only renderer that was in "last-working-1.6" revision, though compared to that revision it contains some small speed improvements and bugfixes to Java part.

Has anyone tried using http://members2.jcom.home.ne.jp/shirowm ... ex_en.html with this yet?

Using SDL_UpdateRects() the best i can get is 30fps, while thats not bad im trying to bring that up.

ive gotten BlitPool to complie(as i understand its workings) BUT im not getting anything drawn to the screen xD.

Added sdl_net and sdl_blitimage libs (did not try to compile sdl_blitimage though), added support to use usual Unix-like configure / make compilation environment for applications, just follow instructions in readme (though each second configure script I've run contained bugs, it compiles LBreakout2 that way but may fail for other apps). Check out LBreakout2 apk - it works really slow with SDL 1.2 software renderer.

Using SDL_UpdateRects() the best i can get is 30fps, while thats not bad im trying to bring that up.

HTC Evo firmware has FPS limit set to 30 (and possibly other phones too), are you sure you did not hit it? Anyway, 30 fps is fast enough for any game I think (though I may check FPS on my ADP1 (which is really slow with SW renderer) if you'll give me .apk)

Edit: ported Jooleem, check it on market.

Im deving on a Nexus One & i dont "think" it has that cap. Ether way my performance has dropped below the 30fps so im gonna try something different as the bottle neck is the actual drawing(tho my code may be fail also xD). Im going to look into using sdl with oGL and see what comes from that...

first gonna try http://olofson.net/mixed.html (which comiles and runs) and see how well it works. if not ill be going full sdl with ogl lol.

I have just read about not using OpenGL for some simple drawing. While it probably conflicts with H/W acceleration, it's a pity I don't have the knownledge in Java/JNI to evaluate this.

kurosu wrote:I have just read about not using OpenGL for some simple drawing. While it probably conflicts with H/W acceleration, it's a pity I don't have the knownledge in Java/JNI to evaluate this.

That approach may be used for video output on Android 1.5 platform, which does not have OpenGL lib (another question: do we really need to support older devices? The software drawing routines will be slower that OpenGL anyway - exactly the same way as it is now with SDL 1.2 SW renderer. See Android version distribution ).
However I totally don't trust that 240 FPS number that was mentioned in the post

Jug6ernaut wrote:Im deving on a Nexus One & i dont "think" it has that cap. Ether way my performance has dropped below the 30fps so im gonna try something different as the bottle neck is the actual drawing(tho my code may be fail also xD). Im going to look into using sdl with oGL and see what comes from that...

If you're developing your own app from scratch it may be easier to use SDL 1.3 - I've managed to do HW acceleration in Alien Blaster, however I had to rewrite most of video output code

pelya wrote:

kurosu wrote:The software drawing routines will be slower that OpenGL anyway

That's what mattered in my initial question. Anyway, it is a moot point because an alternate implementation would be needed, and meanwhile, the 1.2/1.3 fragmentation is eating enough of your time. btw, what do you intend to do with the 1.2 and H/W surfaces (you mentionned using GL textures)?

As for 1.5 platform support, I don't remember which one, but a document from google made me think C++ support was not very good on that platform. I'm also not targetting it for reasons such as older model = weaker CPU. For instance, I may have to compile for a ARMv6 target, rather than the Xscale ARMv5 the ndk uses (our code uses floats, as the fixed point things were too slow).

kurosu wrote:btw, what do you intend to do with the 1.2 and H/W surfaces (you mentionned using GL textures)?

I intend to take parts of code from SDL 1.3 OpenGL ES renderer, and wrap them into SDL 1.2 SDL_Surface API. Ideally the SDL_renderer_gles.c file should be just linked with SDL 1.2, but I'm worried that I'll have to put #ifdef on every second line.

Fine then. Seeing the huge performance drop using SDL 1.3 (both on my phone and under Windows), I'm both eager to see any performance improvement (again, not on my phone) and fearing that not too many parts detrimental to my phone will be brought in. Fortunately this is open source, so I can pick what I want.

Oh, I see now you are linked to a game that could be considered an alternative to Wormux!
Is it the next portage you'll produce?

Im starting to think my bad performance is coming from my lack of understanding form sdl 1.2-1.3. Does anyone have a good tutorial to using sdl 1.3?

kurosu wrote:Oh, I see now you are linked to a game that could be considered an alternative to Wormux!
Is it the next portage you'll produce?

Eh, what game? You mean Jooleem? It's a simple casual game where you have to select marbles of same color. How is that connected to Wormux?

Jug6ernaut wrote:Im starting to think my bad performance is coming from my lack of understanding form sdl 1.2-1.3. Does anyone have a good tutorial to using sdl 1.3?

libsdl.org should have enough of tutorials. Also you may want to look into Alien Blaster sources (and copypaste them).
The main trick with SDL 1.3 is to use SDL_Texture to draw to screen, and to rarely update them - basically you're loading your graphics with IMG_Load() and set colorkey value, then convert it to display pixel format with SDL_DisplayFormat, and then you're creating textures using SDL_CreateTextureFromSurface().
You're drawing to screen using only SDL_RenderCopy() with textures, if you'll use SDL_BlitSurface() to draw on screen it will draw to in-memory surface and do huge memcpy().

Also your device might be just too slow - do you have some other application that gives you more FPS than your code? You may try to test it with GLXGears demo, it does not use SDL surfaces at all and jsut uses OpenGL.