Path: chuka.playstation.co.uk!scea!greg_labrec@interactive.sony.com
From: Elliott Lee <tenchi@netmagic.net>
Newsgroups: scee.yaroze.freetalk.english
Subject: Re: Speed Optimisation
Date: Mon, 23 Feb 1998 17:19:46 -0800
Organization: .
Lines: 82
Message-ID: <34F22032.A62E0C6C@netmagic.net>
References: <34F1D481.5FFF@mdx.ac.uk>
Reply-To: tenchi@netmagic.net
NNTP-Posting-Host: dhcp-e-39-245.cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.03 [en] (Win95; U)

[...]
>         - Only draw the part of the world that is immediately visible
> (in 3D games).

If you can divide your world into logical units/buckets, you'll be able
to save rendering time by identifying only those within a certain visual
range.  You could set the fog paramter to obscure the farther objects so
they don't "pop" into the visual space.  I liked Tomb Raider II's
approach---distant objects go completely black.

>         - Define small often called functions as macros wherever
> possible.

That's great if you don't mind larger code.  Used sparingly, yeah, that
works good.

>         - Use variables which are the same size as the registers (eg
> unsigned long) where ever possible.
>         - Use lookup tables to replace calculations where calculations
> are expensive (eg: floating point, trig functions etc)
>         - Otherwise avoid any floating point arithmetic.

You mean things like fixed-point tables?

	[...]
> And its possible that some traditional optimisation techniques may be
> inappropriate:
>         - eg: loop unrolling was a good optimisation on primitive
> architectures but not neccessarily more modern ones.
> 
> Peter.

Actually, some compilers (when you specify certain optimisation flags)
will do a few tests on their own and unroll loops up to a certain
threshhold.  If you are really desperate for speed, I suppose you could
do a little loop unrolling...



Something commonly overlooked is pointer dereferencing in things like
arrays.  If you're going to be doing lots of testing, it's usually
best to store the values into temporary variables.  e.g.

	// if you have a player walking over a tile of ground and it
	// alters the speed properties...
	if( ground[PlayerX][PlayerY]==WAXED_TILE )
	  friction=0;
	if( ground[PlayerX][PlayerY]==CONCRETE )
          friction=2;
	if( ground[PlayerX][PlayerY]==WATER &&
            (equipment&WATERSKIS) )
	  friction=3;

        //... do some other stuff ...
        ShowTile(x,y,ground[PlayerX][PlayerY]);
	energy-=EnergyDrainer[ground[PlayerX][PlayerY]];

Unless the compiler is really smart, every test must calculate
the offset in the ground[][] array.  Do all the dereferencing once
and get some good savings:

	// get the ground value
	groundval=ground[PlayerX][PlayerY];

	// if you have a player walking over a tile of ground and it
	// alters the speed properties...
	if( groundval==WAXED_TILE ) friction=0;
	if( groundval==CONCRETE )   friction=2;
	if( groundval==WATER && (equipment&WATERSKIS) )
	  friction=3;

        //... do some other stuff ...
        ShowTile(x,y,groundval);
	energy-=EnergyDrainer[groundval];

Especially if you do lots of loops within loops to check a grid of
elements, you gain a lot CPU cycles.

My $0.02,
- e!
  tenchi@netmagic.net
  http://www.netmagic.net/~tenchi/yaroze/