GP2X Fps Problems?


TreeFrog posted on Sep 22 2005 at 12:40 AM said:
Just tried a few things of my own, and I'd suggest trying:

(1) experiment with swapping SDL_SWSURFACE and SDL_HWSURFACE on your various surfaces

(2) toggling SDL_RLEACCEL on and off - for some reason my laptop blits around 20% slower with it turned on...


Finally, DON'T PANIC :D - we really don't know how these speeds will translate to the final hardware, so it's not worth worrying too much just yet... ;)

(1) and (2) Sure, will try them later tonight.

Hehe true true.. As taken from the Hitchhikers Guide to the GP2X. :p

Thanks :)

/sven
 
Last edited by a moderator:
sweetfish posted on Sep 22 2005 at 10:58 PM said:
Oh gosh.. Just tested removing SDL_RLEACCEL, and the FPS jumped from 450 to ~720. So, one hell of a thanks to TreeFrog! :)
Glad to be of assistance :D

If you really need a certain set of sprites/images blitting very very fast, it's possible to make 'compiled sprites' (don't know if this is the technical name).
Basically, you have a hard-coded routine which draws one sprite, pixel by pixel. As the code already knows which pixels to draw, it doesn't have to check the input data to see which pixels are transparent. In addition, if you can assume the sprite won't go off-screen you can avoid doing any clipping

e.g. to draw a small o (4x4 pixel, 16-bit colour, no clipping, to keep this example small, assumes surface is already locked):

void DrawLetter_o( int x, int y, SDL_Surface *screen )
{

// _##_
// #__#
// #__#
// _##_


Uint16 *buffer = ((Uint16 *)screen->pixels) + x + y*screen->w;
int offset = screen->w - 4;
buffer++; *buffer++=0xffff; *buffer++=0xffff; buffer++;
buffer+=offset; //Move to next scanline
*buffer++=0xffff; buffer++; buffer++; *buffer++=0xffff;
buffer+=offset; //Move to next scanline
*buffer++=0xffff; buffer++; buffer++; *buffer++=0xffff;
buffer+=offset; //Move to next scanline
buffer++; *buffer++=0xffff; *buffer++=0xffff; buffer++;
}


However, it's only worth using if you want to draw lots of the same thing.

If you wanted to use this in a real application, you'd probably want to have some way of auto-generating these blocks of code based on some bitmap input data. (And it may be better to write them in assembly code anyway)

If that doesn't make any sense, don't worry about it - unless you're planning on filling the screen several times over with text it's probably overkill :)
 
Last edited by a moderator:
Back
Top