[SDL] sensible optimization [was re: tile based _junk_]
johnsond at westman.wave.ca
Thu Aug 19 19:24:29 PDT 1999
rival games wrote:
> > Ahem, how were you regenerating the screen every time? In one
> > assembly-coded long linear write to the screen buffer (the kind of
> > sensibly optimized 2d engine I was talking about), or unoptimized C
> In your first message, you say not to use assembly code because it's not portable
> (which was grossly patronizing, since there's not one person on this list who
> doesn't know that) And now you're saying I should use it?
Don't twist my words. I said to use assembly sparingly, where you need
it. In a tile-and-sprite game, using assembly to draw your tiles and
sprites is the most (if not the only) logical place.
> > If you haven't made a near-optimal full-regeneration version, how can
> > you claim another strategy is better? The truth is that you are
> > comparing an unoptimized engine to an optimized one, nothing more. This
> Like I said, my engine origionally regenerated the whole screen. I couldn't get it
> at a reasonable framerate. I understand what you say about sacrificing speed for
> more cool effects, but not everyone has a fast enough computer for that.
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
> > To reiterate, I have never said that optimization is bad. I do,
> > however, believe that reusing the unused parts of the screen is a bad
> > optimization; it limits you to modifying only small parts of the screen
> > at a time, so you can't have animated tiles or hundreds of sprites on
> > the screen.
> If you have an animating tile on the screen, you just keep track of it, and update
> it when necessary. And even in StarCraft you rarely ever have 100 sprites on the
> screen, and when you do, it's slow! Even games like tetris have an inconsistant
> frame rate.
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 ...
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.
BTW, I've seen a lot of lousy implementations of Tetris. If one has an
inconsistent frame rate, it belongs firmly in that category.
> > BTW, you don't actually think that you're really running at 150 fps, do
> > you? If nothing else, your monitor can't keep up with that.
> See? Very patronizing...
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".
> Listen, take a look at my code AND THEN tell me what's wrong with it. I can tell
> you one thing wrong, it redraws the screen everytime you move out of a 640x480
> screen, there's a more efficient way to do that, and I know what that is, and I'll
> implement it later. I truly do wish that you were right, I want to be able to
> redraw the whole screen every time. It makes things MUCH easier. But the only way
> I've seen to attain this is to assume the video card has (good) 2D acceleration,
> and I have no intention of that. I would like this to run reasonably fast on a
> Pentium 133.
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.
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.
More information about the SDL