[SDL] sensible optimization [was re: tile based _junk_]
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
> 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