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

Darrell Johnson johnsond at westman.wave.ca
Thu Aug 19 13:09:02 PDT 1999


Frank J Ramsay wrote:
> 
> Darrell Johnson wrote:
> >
> > Honestly guys, I don't think there's any need to go wild optimizing a
> > basic tile-based engine.  Today's computers are awfully fast, and you
> 
> I have to disagree with you about this.  By going 'wild optimizing' a
> tile based engine you increase the number of free CPU cycles for the
> program to do other things.  If that is beffer FX or better enemy unit
> AI. 

The point was that this kind of optimization (reusing the unchanged
parts of the screen) is a compromise, cutting versatility in return for
a very small (in a scrolling engine) performance gain.  You can't use
the extra cycles for better FX, because that would invalidate more of
the screen and you'd lose them again.

> Also you make the game less of a resource hog if it only needs 50%
> the of the CPU time to run at full speed.  Sure that eats up the cycles
> elimiating your enhancement, but that is WHY you did the enhancement,
> to allow for those additions.  Not to mention that by super optimizing
> the engine, you reduce the resources the games requires.  If your game
> needs a PII-450 w/256Meg of RAM to run, how many people do you think
> are going to get a copy?  Remember not everyone has a high end computer,
> there are a _lot_ of people with P-166's (I'd say _most_ home computers
> are a P-166 or below) If you can optimize the same game so it runs
> on a P-150 w/32Meg you will have a much larger audience pool.  

We're talking about a simple scroller!  Any Pentium system, and most
486ers, will do fine while regenerating the whole screen every frame.

While we're on the subject, the sad truth is that if you're selling
games, the kind of people that have PII-450s w/256meg are the kind of
people who have money and take their gaming seriously and actually pay
for games - a pretty rare thing among computer owners.  However, this is
completely offtopic and I imagine a fair number on this list are making
free stuff anyway.

> Writing
> sloppy code that needs a huge amount of resources simply because your
> computer has those resources leads to code bloat  Witness Lotus Notes,
> a 200 Meg e-mail program (yes it does more than e-mail, but that all 80%
> of people use it for)

I never said to write sloppy code.  If you had bothered to read the
whole text of my message instead of just the paragraph you quoted, you'd
see that I said to concentrate your efforts on fundamental and necessary
improvements, not complex and superfluous hacks.

Here are some tips on making a fundamentally sound 2d graphics engine:
-first choose efficient data structures and algorithms; this is the
front line of optimization, where you can make hundredfold improvements
-keep seperate components seperate whenever possible, so you can modify
or replace one part without changing others
-try to access memory in a linear fashion whenever possible, cache hits
are your best friends on today's fast computers with slow memories
-think versatility: don't start off by optimizing around your intent to
allow only horizontal scrolling, or assuming that you won't ever want
sprites to overlap, or you won't want to cover the entire surface with
sprites or animate tiles; in general this means regenerating the entire
screen with every frame
-write the whole thing in C (or C++) first, get it working so you
understand the problems; you might find out that it is fast enough
without any more fiddling, and if you run out of time or motivation
you'll be glad to have something working instead of some really great
ideas on how to make it go fast
-use a profiler; whatever you think you know, you don't know which part
of your code is taking all the cycles until you use a profiler
-before writing assembly code, write a C equivalent and examine the
compiler's assembly output; don't be too surprised if the compiler does
a better job than you would have, or if it misses out on an obvious
opimization
-keep assembly to a minimum; as a rule, you shouldn't rewrite anything
in assembly that takes up (by itself!) less than 20% of CPU load; the
way things are going, you might be really glad to be able to recompile
to a new platform with minimal changes
-when you have done everything else, and it's still too slow, _then_
consider adding optimizations that exploit the details of your
particular game (examples: one-way scrolling in Super Mario Brothers,
tile-by-tile stepping in many CRPGs, level floors and plumb walls in
Doom)

I hate slow, bloated software as much as the next guy, but there are
sensible optimizations and silly ones.

Cheers,

Darrell Johnson



More information about the SDL mailing list