GP2X Fps Problems?

[sweetfish]

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 - 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.

Thanks

/sven

 

[darkplayer]

im serious! I dont know why i got that high...

 

[sweetfish]

Oh gosh.. Just tested removing SDL_RLEACCEL, and the FPS jumped from 450 to ~720. So, one hell of a thanks to TreeFrog!

 

[TreeFrog]

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

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