🚀 go-pugleaf

bp092@cleveland.Freenet.Edu (Mike Ogrinz) writes:
>
>I'd say most of us have seen Origin's bitmap 3-d space system in WC and
>WC II (and other stuff) and maybe in Star Trek 25th Anniversary.
>
>First off, let me say that WC (1&2) do not map textures over polygons->
>It seems that they must capture a bunch of bitmaps for each object,
>and they just display the correct one probably according to some
>'direction facing' vector in each data structure. I'd bet there's
>also a velocity vector. When used with the 'direction facing' vector
>that would produce stuff like the debris and asteroids which spin
>in one direction and move in another.

This is an incredibly memory-intensive way to do things, but it's also
incredibly simple (and therefore fast).  It also has has the virtue
that you can make the rotated images look "perfect;" i.e., you can pay
your artist to draw each view by hand (or, more realistically perhaps,
to touch up texture-mapped solids you've already rotated with
Autodesk).

For static (i.e., non-animating) objects, you just need to store a
three-dimensional array of images: as the viewpoint moves left and
right, you move your frame pointer through the array along x; as the
viewpoint moves up and down, you move along y; similarly with
closer/nearer and z.

Note that this only encodes a single frame, but it enocdes that frame
from every possible viewing angle.  If you want to add animation, you
need to add a fourth dimension (time).  If you want multiple animations
(for example, rock spinining one way vs. rock spinning another), you
need to either add a fifth dimension.

You can eliminate a dimension with real-time scaling.  You can
eliminate another dimension in special cases with real-time rotation
(e.g., to get a rock spinning clockwise, just hflip the rock spinning
counterclockwise in real time).

A further space saver might be to disallow certain coordinates; e.g.,
in a head-on space dogfight you might never allow the player to look
straight down on top of a particular object (or even come close).

Probably the biggest space-saver would be to only store deltas between
frames.  I.e., you'd only store the changes from one view to the next.
This would restrict you to changing the view incrementally since to
"teleport" to a particular view from any current view would require you
to take the starting frame (0, 0, 0) -- the only fully-specified one --
and step through to your destination, applying deltas as you went.
This restriction would probably be fine for a space game.

There are probably many other possible optimizations as well.

Dave Baggett
dmb@wam.umd.edu