Gp2x Performance Questions


otaco

Still Fresh
Joined
Sep 14, 2007
Messages
91
Location
Germany, Weimar
Website
www.otaco.de
Hi,
I'm programming a little 2D sprite-particle-game-collision-thing using the SDL. I don't have seen a gp2x jet (I plan to buy the F200 in October) so I have some performance questions some of you folks surly can answer:

1. How munch Ram I have left for my program after the system is loaded (64Mb-x?) ?

2. How fast is the SDL_BlitSurface function on the gp2x with and without per pixel alpha? For example: on my Laptop i can blit more than 50000 Sprites (with 1x1, 2x2, 4x4 pixels) at 60 Hz.

3. What is a good screen refresh rate on the gp2x ? 30 Hz, 40Hz, 50 Hz or 60 Hz, ... ?

Thanks for your answers, other questions will surly coming up later.

Here are some impressions of my work so far. If there is some interest, i can post a link to the doxygen docs of my code and a the code itself. It's all open-source.

( Visit me at http://www.otaco.de )

screen_01.jpg


screen_02.jpg


alien_aster.gif


particle_stress.jpg


underconst.jpg
 
Well a particle engine is something I need for my engine... so I'd like access to that code :)

Things are looking good there so far!

1) By default you only have access to the 1st 32MB ... I think the MMUHack unlocks the other 64MB for you... but someone else would be better to clarify.
I wouldn't worry too much about the RAM in any case... Just make sure to free it up when you are not needing some resources and it will be fine.
2) SDL defaults to VSync... but you can disable IIRC. How fast you run your physics timer depends on the game... 30fps is good enough for most purposes on the little 2X screen... but it really is dependant. Notaz's PicoDrive sets the refresh to 120Hz for NTSC MegaDrive games and it looks very very nice! So yeah it really is up to you.
 
Ah one thing I do notice straight away... if you want to use that on the 2X, you might want to consider converting some thing over to fixed point, since the 2X doesn't have an FPU.

It doesn't suffer too much with floats with the softfloat option, but fixed point will grant you more performance.
 
It looks great, but don't expect the GP2X to blit 50000 sprites, not even at 6fps ;P
 
For my first project on the gp2x I plan a Asteroids-like game with scrollable levels, some boni and a shop between the levels. You have to clear the stages from enemies as fast as possible and with a good hit quote to earn money for the shop (Do you know the game transplant on the Amiga?, much like that).

If anybody has some ideas or wishes for such a game I would be glad to hear them.


screen_03.jpg


title_artwork.jpg
 
If you have made something which works fine on your PC, and you make a straight port to the GP2X, then you will be disappointed, more disappointed than what you can expect.

My intuition is that it will be especially painful for a particle engine. I don't know how you coded that, but on a PC, I guess you have used floats. Forget them on the GP2X (no FPU, about 1000 times slower than on a modern PC).

A game called noiz2sa, which contains something similar to a particle engine, has been ported to GP2X. In its first version (direct port), it was painfully slow. Now, some people have deeply optimized it, and still it is not always fullspeed. And it does not use nearly as much particles as your engine seems to do.

About the available memory, it is about 20-25 Meg (as far as I remember) from the first 32 Meg. For the upper 32 Meg, there is no MMU. You can store data using some hacks, but you can't just malloc it.
 
Thanks hal9000,

I expected something very slow so I tried to optimize everything I could. I found some fixed point classes I will use via typedef to use the same code on both systems.

I updated the reference if somebody want take a look.

SDLE Reference

I would be happy to get some feetback. A usable release of the engine code will happen soon.

screen_04.jpg


screen_05.jpg
 
hey there,

that looks really good. the SDL of the GP2X (paeryn's) version supports hardware colour keying but no alpha. Alpha would need to be done in software making it considerably slower. But still, you got a 200+ MHz ARM9 with some rudimentary dsp support. You should be able to get a few thousand sprites moving in 1 VBL..

earx
 
otaco said:
Thanks hal9000,

I expected something very slow so I tried to optimize everything I could. I found some fixed point classes I will use via typedef to use the same code on both systems.
There is a game called "Thruster" for the GP2X that uses particles. It is basically an enhanced Spout re-make. It works very smooth. It doesn't use nearly as many particles as your engine. Maybe you can cut down on the amount of particles on the GP2X version.
 
Last edited by a moderator:
Back
Top