I dont know if anyone posted this yet, but... As soon as you said that you are drawing the entire background, that caught my eye. Your slowness is probably because the bit depth of your surfaces are not matching up to the bit depth of the screen. To solve this problem, there are SDL functions which convert a surface to a surface which is compatible to the screen. I believe its something like "SDL_ConvertSurface()". Just look it up in the docs. Make sure you convert all of your surfaces using this function before you blit any of them. This should increase performance by a lot, since the way you have it now is that SDL converts the bith depth on the fly each time you blit it (SLOW). Of course, the images might already match up so my theory could be totally wrong.

Quote:

Original post by graveyard filla I dont know if anyone posted this yet, but... As soon as you said that you are drawing the entire background, that caught my eye. Your slowness is probably because the bit depth of your surfaces are not matching up to the bit depth of the screen. To solve this problem, there are SDL functions which convert a surface to a surface which is compatible to the screen. I believe its something like "SDL_ConvertSurface()". Just look it up in the docs. Make sure you convert all of your surfaces using this function before you blit any of them. This should increase performance by a lot, since the way you have it now is that SDL converts the bith depth on the fly each time you blit it (SLOW). Of course, the images might already match up so my theory could be totally wrong.

I'm not blitting any images at all.

Everything is being drawn via SDL_FillRect(); The func you are referring to is SDL_DisplayFormat(), but that's not it, since I'm not doing any blits at all.

I didn't say I was drawing the entire screen, I said I blank the entire screen by doing a fill rect with black. Then I am drawing each element, but everything is just a plain rectangle, so I'm not blitting.

hmm, thats odd then. i found SDL to be too slow for my needs too. you might want to consider OpenGL if your going to invest some serious time in your project. however, if this is just a small game made for learning then i would stick with SDL, you should focus on learning how to write good code and make games and not how to render things to the screen. it will be easier to learn OpenGL when you have a decent knowledge of how the basics of stuff works. OpenGL isn't that hard to do simple 2D stuff with though.

Post your code please. There's many things that can cause this that arent obvious.

A few things that come to mind are...

1. The bit depth setting, considering your set up you should be doing 32 bit no matter what, using anything else can dramatically effect frame rates.

2. Use the SDL_GetVideoInfo() function before and after you create the display surface and see if any thing looks strange there. On my old computer I kept trying to set the video surface as 32-bit, but for some reason could only support 8, 16, and 24. SDL was forcing the display to 24-bit causing a tremendous bottle neck in the blitting. I figured that out with SDL_GetVideoInfo().

3. Probably not worth mentioning but, do you have any other programs running that could be eating up the CPU?

4. When you call SDL_FillRect() does it return 0 or -1? Do you check the return codes on all other applicable functions?

This should be in the FAQ really. SDL cannot make use of the advanced rendering capabilities of your graphics card so you can't compare its performance to any game that uses Direct3D or OpenGL. SDL_FillRect in particular is likely to be a very slow operation since the system colours in the screen pixel by pixel. You might find you get slightly better results with real sprite blitting but you will still find your graphics card is largely sitting idle.

speaking of which... how is that library comming?

Quote:

Original post by Kylotan This should be in the FAQ really. SDL cannot make use of the advanced rendering capabilities of your graphics card so you can't compare its performance to any game that uses Direct3D or OpenGL. SDL_FillRect in particular is likely to be a very slow operation since the system colours in the screen pixel by pixel. You might find you get slightly better results with real sprite blitting but you will still find your graphics card is largely sitting idle.

Kylotan is the winner.

I rewrote all my drawing routines to use OpenGL instead of SDL. All the other code - collision detection, animation, etc is exactly the same.

I now get ~1935 fps.

I guess I will be moving to OpenGL from now on. I like SDL's window management / input / sound etc code, so I will still use it. But it seems to have a sever shortcoming as a renderer.

Thanks for all the input, guys.