RE: [GD-Consoles] what to do with little cash

[Christopher P. <cph...@re...>]

We certainly got some decent performance gains on PS1 by breaking up our
vehicle code into 'wheel <-> ground' interactions and 'car body <-> ground'
interactions.  Two separate loops over all cars, with the MapHeight()
function positioned between them in the handling code.  Managed to kill 90%
of the i-cache misses.  This helped us a lot more than copying a few bits of
the car structure into scratchpad did.

Before we moved the ground height code into the vehicle handling source, we
had to regularly examine the .map file and fiddle a dummy routine padded
with nops to sort out the cache alignment, and later found the handling code
was stretching out to near 4k anyway as more features went in.  Much saner
just to put relevant bits of code in the same file.  That was in C - C++
probably makes managing this stuff harder, although inlining can help. Oh,
and the PS2 has a marginally less brain-dead i-cache, which also helps ;-)

Christopher Phillips


-----Original Message-----
From: Mick West [mailto:mi...@ne...]
Sent: 25 February 2003 01:35
To: gam...@li...
Subject: RE: [GD-Consoles] what to do with little cash


I've got a related question:

(Assuming a PS2 style console)

Given that you have game objects that are composed of various components
(car = physics + collision + AI + script + sound, eg..).    Is it better to
process this "per-object" (where you iterate over the objects, and updated
all its components), or "per-component" (where for each type of component,
you iterate over each instance of the component type, and update it)

Per-component might give you better usage of the I-Cache, but per-object
might give you better D-Cache usage.

Again, I suspect that "it depends", but has anyone thought about this?
Anyone tried restructuring code one way or the other?

Mick.

-Virus scanned and cleared ok