[SDL] sensible optimization [was re: tile based _junk_]
Frank J Ramsay
fjr at epsilon.com
Thu Aug 19 12:52:37 PDT 1999
Darrell Johnson wrote:
> Frank J Ramsay wrote:
> > 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.
That depends upon the kind of game you are writing, for instance, a
stragegy game like Warcraft or Civ re-using unchanged parts of the
display makes since because (I) would render the game in layers and
matte the layers together on the back buffer.
Yes, the entire screen will have to be re-freshed, but there is often
no need to re-render the entire screen when you can do linear memory
access to re-build the unchanged portions.
[snip, my little rant aboud resource usage and varius systems]
> We're talking about a simple scroller! Any Pentium system, and most
> 486ers, will do fine while regenerating the whole screen every frame.
Scrollers are not the only tile based games out there, most strategy games
are tile based as well. The exact game that (damn, can't find the post) is
discussing is a 'simple scroller', that doesn't mean that the techniques
could not be applied to a StarCraft clone that requires 20 fps regardless of the
work being done, then you really need an optimized engine.
Now for an example. When I started writing (actually porting from DOS) the
Isomentric engine I'm working on, at a resolution of 320x200 is got around
12 fps on a P-150MMX w/32Meg This did full screen refreshes for every frame.
[snip-some comments on computers]
> > 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
Fair enough, sloppy was a poor choice in words, perhaps less efficient would
have been better.
> 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.
superfluous, that would depend upon your needs.
hacks, well I didn't see anything in the thread I would call a hack.
His design seemed rather well planned and thought out. Not a quick fix
to get speed.
[snip, a whole bunch of really good advice]
>-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
[snip - the rest of the above mentioned advice]
I wanted to comment on this one item, Don't try to make your code
so versitile that it takes 5 times (I just picked a number at random) as
long to draw as you need. Yes, plan your engine so that you can expand
it, but don't make it so flexible that a simple task takes 5 times longer
than is needed. Keep your intent in mind, and when optimizing ask yourself,
does _this_ engine really need to handle animated tiles? If you want animated
water, do you really need 2 tiles? or can use use palette rolling with one tile
and then not have to refresh the screen at all?
Frank J. Ramsay - Software Engineer, Epsilon Data Management
fjr at epsilon.com
framsay at epsilon.com
Genetic Engineering: (noun) Proactive Evolution.
More information about the SDL