[SDL] sensible optimization [was re: tile based _junk_]

rival games rival at Nayzak.com
Thu Aug 19 19:35:21 PDT 1999


> Yes, like I said, your original unoptimized engine was too slow.  You
> added an optimization and now it goes faster.  This doesn't imply
> anything else; certainly nothing about the inherent superiority of dirty
> rectangle methods.

The way my system works, if everything on the screen needs to be updated, the slowest
it will go is as if I was redrawing the whole screen every time. Now how is that
inefficient?

> If you have a single animating tile, you can treat it like a sprite.  If
> you want your tiles to be animated, with grass rustling in the wind, or
> machinery in the background ...

Then you keep track of them and update them when necessary. It's pretty simple.

> Starcraft slows down when there are lots of units, partly because of the
> extra AI it must do, but it is logical that it would slow down somewhat
> when there are a great many sprites onscreen.  If it covered the entire
> screen with sprites, it would have to draw twice as many pixels (or some
> similar overhead); however, if it used and needed a dirty rectangle
> strategy, it would have to draw dozens of times the normal number of
> pixels, and it would go from >30 FPS to <5 FPS.

Not if they use a system like mine.

> BTW, I've seen a lot of lousy implementations of Tetris.  If one has an
> inconsistent frame rate, it belongs firmly in that category.

I'm sure those implementations redraw the whole screen every time too.

> I don't care if I seem patronizing.  If you're redrawing the screen
> multiple times between refreshes, that's a flaw in your program, and a
> flawed benchmark.  Redraw at most once per refresh and report CPU idle
> time if you want a real benchmark beyond "fast enough".

If a program runs fast enough to update the "screen" more than 18.2 times a second,
then it's "fast enough." Even quake doesn't wait for retrace.

> All right, I'll tell you what's wrong with it right now: you're using
> SDL_BlitSurface to draw your tiles; this is totally inappropriate
> (workable for strategy games, perhaps, but not for action games).  If
> you think your old engine was bad, try switching it to much smaller
> tiles.  Locking and writing directly to the buffer would be a good
> start; I'd assumed you'd have taken that most basic step already.
> Regardless, this fits very nicely with my evaluation of having a
> trivially easy slow method for painting your tiles, and a trivally easy
> fast one for copying big blocks.

Not use SDL_BlitSurface? What _portable_ way do you have in mind?

> Like I also said, you're not going to take too much of a performance hit
> moving to a Pentium 133.  I'd be surprised if even your old, slow engine
> went slower than an entirely playable 20 FPS on most P133 systems; an
> optimal full-redraw page-flipping system could possibly be limited by
> the monitor's refresh rate.

If you consider 20 fps an  "entirely playable" framerate, you really do come from
programming databases. Even Arjan Brusee (made some jazz jackrabbit 2 game) says
redrawing the whole screen every frame is too slow. But I'm sure you've made plenty of
blockbuster platform games too.

-= aaron p. matthews




More information about the SDL mailing list