GP2X Fps Problems?


sweetfish

Still Fresh
Joined
Sep 19, 2005
Messages
46
Location
Gothenburg, Sweden
Website
md5.se
Hi again :)

I've been having some pretty low FPS (imo) on my SDL-project... Currently it's going at ~700-800 FPS when printing about 16 (quads (you could say I'm blitting about 16 times per frame)), background (1) + text (15)... When comparing to OpenGL it's seems really low, but then again, OpenGL is hardware rendering and SDL isn't, right?

So the question is, should I try to optimize the code in some way (currently don't know of any good optimizations for my code), or is the FPS sufficient?

My best guesses says it's the text-rendering that's slowing it down, cause it uses transparency and is one blit per char.

Also, if anyone else is programming, what are your games/apps running at?

I would also be glad if you tested my app on your comp and report back your FPS:
http://dump.grendosa.com/rel002.rar

Yours,
Sven, Sweden
 
TheWizzard posted on Sep 21 2005 at 05:45 PM said:
Ahh

I havent started your app, I'm mac based, but I think 700-800 frames isnt all that bad.
Oh and I had a look at your gfx, why are you using your own text drawing mechanism?
There is a module called sdl_ttf, and that's what it does, render ttf fonts.

http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fttf

The reason I havn't used sdl_ttf is that with my own function I can render text from a charmap, which can be created with any imagesoftware. And that makes it easy to create nice "effects" to the "fonts" and such... But if it's my textfunction thats slowing things down, I maybe will take a second look at sdl_ttf.

But then again, I think the main reason why things are slow is that I'm blitting for every char... ...but blitting 16 times per frame is not much and it shouldn't be so dramatic, I think. :(
 
Last edited by a moderator:
I'd expect TTF rendering to be much slower than simply blitting characters - rasterising a truetype font is quite complex.

In terms of speed, are you blitting straight to the screen or to a memory-resident surface? It's normally quicker to blit everything to a memory surface then have a final step that copies this to the screen.

The other thing to try is double how many characters you're drawing and see how much the framerate changes (i.e. that may not be the bottleneck)

<edit> runs about 450fps on my PC
 
Didn't think about that one. I also think it would be best do double the chars. Then we will see.
 
Other things to bear in mind:
Try running it fullscreen - my SDL apps run noticably quicker in fullscreen than in a window

Are all your surfaces in the same pixel format? - format conversions will slow things down significantly

Do you really need full alpha blending on your font? Perhaps consider just using color-keying (and enabling RLE (run-length encoding) on your font surface)

Hope something there helps :)
 
TreeFrog posted on Sep 21 2005 at 06:06 PM said:
I'd expect TTF rendering to be much slower than simply blitting characters - rasterising a truetype font is quite complex.

In terms of speed, are you blitting straight to the screen or to a memory-resident surface? It's normally quicker to blit everything to a memory surface then have a final step that copies this to the screen.

The other thing to try is double how many characters you're drawing and see how much the framerate changes (i.e. that may not be the bottleneck)

<edit> runs about 450fps on my PC

I just tried creating a SDL_CreateRGBSurface() and blitting everything to it instead, and then at the end blit the buffersurface to the screensurface, but got a huge FPS drop. :(
Maybe I'm doing it wrong?

Also tried SDL_Flip (with the SDL_SetVideoMode flag SDL_DOUBLEBUF) but no difference.


TreeFrog posted on Sep 21 2005 at 06:27 PM said:
Other things to bear in mind:
Try running it fullscreen - my SDL apps run noticably quicker in fullscreen than in a window

Are all your surfaces in the same pixel format? - format conversions will slow things down significantly

Do you really need full alpha blending on your font? Perhaps consider just using color-keying (and enabling RLE (run-length encoding) on your font surface)

Hope something there helps :)


Running the app in fullscreen now, and no speed up as far as I can se.

Also trying to SDL_ConvertSurface on every "texture" surface, but no difference.

Sorry if I said alpha blending. :p I don't really know what it's called, but I'm doing as you said, color-keying.


Although, I added some more chars now and the FPS dropped to about ~300-400 on my pc. :S

I would be glad if you peeps try the new version:
Note: Press Q to select which string to display.
http://dump.grendosa.com/rel003.rar

Yours,
Sven
 
Last edited by a moderator:
Vimacs posted on Sep 21 2005 at 09:49 PM said:
maybe you should try it at gp32 for a good speed compairsion?
Hm, havn't coded anything for the gp32, and does not own one.. :p

Saido posted on Sep 21 2005 at 09:56 PM said:
I want your font code it's nice :D
Sure, I'll release it later I think. (It's nothing special, but hey.) :)

Quiest posted on Sep 21 2005 at 09:57 PM said:
Erm what FPS would be good at fast enough?
Or isn`t this serious?
It's a big difference between a modern PC and the GP2X so every decrease in the FPS does mean alot.

Saido posted on Sep 21 2005 at 10:00 PM said:
Ey are you saying you are blitting every single character?
I'd say change your character render function to put your text on one single piece and then blit it.
Erm, what do you mean? Blitting an image with the text? The text is dynamic so it will change alot, so that won't work (if it's that you mean?)... Please explain. :p

And thanks to the guys who reported their FPS!
 
Last edited by a moderator:
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... ;)
 
Back
Top