Hi Paul,

yes, your post helps a lot.
I've seen that you've been working with the GP2X and was kinda hoping that you'd have some advice for me.

Crashblock uses SDLMixer for all of it's sound, so any movement on this mixer issue would be important for me.
All of the sound effects are OGG Vorbis. I've noticed that ogg playback can be a little choppy.. is this something you've found too?


I use PNG's for a lot of the graphics, at the moment only so my transparent colour doesn't get smudged in the compression (as would happen with a jpg)
But with the lower resolution, I was considering using the PNG Alpha channel to improve the image quality.

Perhaps there are some updates to SDL for pngs and ogg vorbis?

Most of the grunt work done in Crashblock is image rendering, I'm hoping that a 40% decrease in image size will help with many performance aspects.. including collision detection. But I'm not sure if it'll be enough.. I guess only by testing will I find out.

Also, Crashblock runs in 16bit colour. Would reducing this further to 8bit make things run faster? What are you using?.. if the GP2X's resolution is 16bit (not sure) then translating between 8 and 16 will use eat processor cycles.

have you noticed any performance differences between using pure SDL and your direct framebuffer code? If so, is it an extreme difference? I would have thought that SDL would do a reasonable job of accessing the frame buffer.

It's a very cool console and I really want to get Crashblock working on it.