Game Development Reference
The rigid-body integration algorithm is a particular candidate for this. We can
speed things up by having it process four objects at the same time. To do this, however,
we would need to rearrange how data is held for each rigid body.
For the sake of an object-oriented programming style, we've used a class contain-
ing all the data for one rigid body. To take advantage of simultaneous processing we
need to “twizzle” the data, so it is grouped together: the position for each object in an
array, followed by all the velocities, and so on. This can be achieved by using a new
data structure that holds four rigid bodies at a time.
Personally I have never implemented this in any physics engine I have built. Some
of the AI engine development I've been involved with, however, has used this struc-
ture, with four characters being updated at once.
Grouping Data for Areas of the Level
Memory management is a crucial part of optimizing game technologies. There is
plenty of memory available on most games machines for physics, but its organiza-
tion can cause slow-downs.
Processors don't have equal access to all parts of the memory. They load data in
chunks from the main memory and keep it in high-speed caches. Accessing data from
the cache is fast. If the data needed isn't in the cache, then it has to be fetched from
main memory, which can be very time consuming. Different machines have different
cache sizes, and some have several levels of cache.
To avoid constantly fetching new data into the cache, data should be grouped
together. For small game levels all the physics data can be easily kept together. For
medium-size game levels care must be taken that the physics data isn't simply added
into another data structure. For example:
This can easily make the rigid-body data for consecutive objects a long distance
apart in memory. When resolving collisions among many objects, data can quite eas-
ily need to be fetched to the cache on most resolution steps, causing disastrous per-