[SDL] Anyway around SDL_UpdateRect?

Paul Lowe spazz at ulink.net
Thu Aug 26 14:44:32 PDT 1999

John Garrison wrote:

> I really hate to be a pain and sound like I am complaining, but I have
> had several people complain about PowerPak being slow and it is really
> beginning to annoy me.

Did you advertise your product? don't be surprised if you did.

>  When I created it I just wanted to help
> beginners program games on an environment like I had a few years back
> (Allegro for DOS) I had no idea that people would actually complain
> about it, I mean if they don't like my work that I am give away free and
> spent all my valuable time on, why don't they just write their own code?

Cuz they want something easy, but fast.

> If they can't write thier own code then they have no business
> complaining that mine is slow.

Sure they can. They can bitch about it if they think it could be better,
lots of people complain about DirectX all the time.

> The speed problem is definetly in SDL_UpdateRects.

Dirty rectangle updates suck man. Use a framebuffer.

>  My graphics card
> doesn't support SDL's DoubleBuffer so I will have to add native double
> buffer support back to powerpak, but that will be just as slow because I
> will have to call update rects. I even tried a memcpy directly to
> screen->pixels and still have to call SDL_UpdateRects. Isn't there
> anyway at all to directly access the screen and still have the features
> of SDL.

Write everything to screen->pixels, use SDL_UpdateRect, USE A FRAMEBUFFER!
If you want the most speed possible, ultimate speed, you could write your
own blit routines.

> I don't know how to support multiple depths and alpha values and
> stuff so it is not at all feasible for me to write it all over from
> scratch.

Specialize in one bit depth. Such as I did with my graphix lib which is 16
bits *only*. That way it's streamlined and optimized and you'll get the max

>  I realize that a dirty rectangles type situation would greatly
> speed things up, but there are engines (tile based, voxel graphics, 3d
> graphics) that have to update the entire screen everytime and being
> stuck in a 27fps framerate with a 400mhz isn't very good.

Consider bit depth here dude. 8 bits goes *fast*.  But 32 and 24 are perty

You can get more than 27 fps. What depth are you running your X server in?
What depth is your program running in? 32 bpp is some heavy shit, 8 is fast
but limited, that's why I chose 16. Lots of games today are 16 bits too.
Conversion will slow you down a lot too.

> Doesn't CivCTP use SDL? How come that is so fast on my computer (Yes, I
> know you can't reveal that Sam :)) Actually I guess I know the answer
> Civ doesn't need to update the whole screen until scrolling time comes
> around. Still CivCTP's isometric engine scrolls ten times faster than my
> simple square tile based implementation. Dos Loki use a 'suped up'
> version of SDL?

Civ scrolls at a blocky rate ( I mean it scrolls in large amounts, not by 2
pixels at a time ) StarCraft is an example, it scrolls at about one tile per
frame of scroll, which is pretty jerky, but you don't notice it.

> Does anybody have any examples of a doublebuffer implementation in SDL?
> All I want to to have people stop insulting that which have have
> practically dedicated the past 2 and half months of my live to.

People will continue to insult if you boast an inferior product (I've never
used PowerPacker so I don't know if it's good or not), but they don't need
to insult, they could be polite and use constructive criticism.

> Thanks for any help,

Take my advice / talk with a grain of salt :)

Paul Lowe
spazz at ulink.net

More information about the SDL mailing list