SDL general speed up tips?

[Gilzu]

Wow thanks guys! Will check out your suggestions. Gilzu - are you certain you've tried that with the new .10 release? It is chopping my framerate in half when I do....

nope, but i've just installed it, recompiled it - and no change in framerate (100+-).

You might want to check the following:
1. I don't use alpha blending - could it be that this is the cause for the low framerate?
2. check for absolutly *every* surface - should all be in the same memory, and in the same format.
3. Are you releasing every surface?
4. if all of the above doesn't help, i'd go with elimination - /*wrap segments of code and see what exactly causes the problem. */. I used to have a similiar problem, which was caused by my personal-made font unit (!)

and as a side notice - finally they implemented:

Pressing ALT-F4 now delivers an SDL_QUIT event to SDL applications.

[mahlzeit]

I would link with the previous SDL release and see if it's still so slow. Maybe you're looking in the wrong place for the cause of the problem.

[Robert Cummings]

Hiya,

I tried the previous .9 SDL release and I found it to be even slower. .10 is actually optimised.

I've checked every single surface and no matter what I do, its faster when I don't optimise! This is true for the p2-400 with S3, and the x1900XT on the Dual core pc.

All surfaces however are alpha blended, apart from the background which is solid blended. I am not sure if I got SolidBlend correct, I think it is SDL_SetColorKey( surface , SDL_SRCCOLORKEY|SDL_RLEACCEL , 0 ) with SDL_SetAlpha( surf , SDL_SRCALPHA | SDL_RLEACCEL , 255 ) ?

In any case - why not try for yourselves - I am finding surfaces with alpha information rendering way faster without optimizing (converting to display type).

[Spaceman Spiff]

Robert,
I'm not sure of the exact name for it. Basically, it is for updating surfaces with lots of irregularly shaped sprites/whatever. Instead of keeping a list of rectangular areas to update/invalidate, you keep a list of horizontal spans for each line of pixels on the surface. Let's call it "span lists".

To make this useful, you need to have the horizontal bounds of each line of each item drawn.

Imagine you have a tree sprite with a tall trunk and wide top. The rest is transparent/ not drawn. I'd draw an ASCII representation, but this forum editor removes multiple spaces/indents. Now, draw a bounding box around it. Ok, on either side of the trunk is a whole lot of 'dead' space where nothing is going to be drawn, but is going to be updated / redrawn / invalidated / whatever anyway.

So instead of a simple bounding box, you record the x offset of the first and last pixel drawn on each line. For the top of the tree, this would represent a span width nearly the width of the bounding box. For the trunk, it would be just a tiny, narrow strip.

Do this for everything and you have a more accurate picture of which pixels on the surface are going to be updated (holes in objects excepted) with a smaller total area/ number of pixels than using simple bounding boxes / dirty rectangles.

This alone can be useful, but you can take it a step further if you feel like writing the drawing routines. What you do is generate the span lists in a pre-pass (keep info on every item drawn in the previous frame. If it unchanged this frame, don't add it to the span lists). Then you draw *everything* clipped against the span lists. That is, the span lists represent the valid update area. Really -- this works. If you have a large visual that is unchanged, but overlaps a tiny changed area, redrawing just that tiny portion of it can be a huge performance savings.

Ultimately, this all depends on the type of visuals you are drawing. If everything is rectangular, then this won't help much. If you have plenty of irregular shapes, it can help a lot. Clipping partially involved images can help a lot in both approaches.

[mahlzeit]

I am not sure if I got SolidBlend correct

EDIT: What I said here doesn't make any sense. Maybe try without the RLE flag, though.