🚀 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

> First off, let me say that WC (1&2) do not map textures over polygons->
> at least not for the ships. The images are simple bitmaps that were
> captured from Autodesk (where they were wireframed and phong shaded ).

You're right on the nose.  We figured out the system a few months after
they released it.

> 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.

You're on there too.

The number of pictures seems to vary, however.  For instance, that ship 
that looks like it has fuel things on it...it jumps a lot more.

> Star Trek seems to jump a little, which is what you would expect from
> having only a fixed number of stored views, yet WC is much smoother.
> I'd like to know why. Any germ of wisdom you TP and C++ programmers
> have out there would be much appreciated!

Have you figured out the rotation code yet???  You'll die when you figure
out how simple it is...

Josh

I wonder if it would be possible to use the graphic system in WC or
say, Falcon. If the entry points of the appropriate routines could be
weeded out and documented, one could use them for one's own project.
I.e. to run the freeware space blasters, one must have Falcon on the
hard drive, from which the appropriate code is extracted at run time.
Perfectly legal. I'd like it for prototyping at least.

Sean

-- 
                  |``Wind, waves, etc. are breakdowns in the face of the
Sean Casey        | commitment to getting from here to there. But they are the
sean@s.ms.uky.edu | conditions for sailing -- not something to be gotten rid
U of KY, Lexington| of, but something to be danced with.''

In article <1992Jul31.02556.1505@ms.uky.edu> sean@ms.uky.edu (Sean Casey) writes:
>I wonder if it would be possible to use the graphic system in WC or
>say, Falcon. If the entry points of the appropriate routines could be
>weeded out and documented, one could use them for one's own project.
>I.e. to run the freeware space blasters, one must have Falcon on the
>hard drive, from which the appropriate code is extracted at run time.
>Perfectly legal. I'd like it for prototyping at least.
>
Not really... many disk packs I've seen clearly state "this program
may not be disassembled..."


-- 
 _____________________________________________________________________________
|                                                                             |
| "Nuke the unborn gay whales!" |  millerje@cs.colostate.edu  |  Jeff Miller  |
|_____________________________________________________________________________|

> I wonder if it would be possible to use the graphic system in WC or
> say, Falcon. If the entry points of the appropriate routines could be
> weeded out and documented, one could use them for one's own project.
> I.e. to run the freeware space blasters, one must have Falcon on the
> hard drive, from which the appropriate code is extracted at run time.
> Perfectly legal. I'd like it for prototyping at least.

I doubt it.  Wing Commander's system and Falcon's system are two 
different things.  Falcon is a flight simulator...WC is, well, a 
simulation.  Strike Commander will probably be closer to FAlcon
than WC.

Josh

------------
Sig under construction

millerje@CS.ColoState.EDU (Jeff Miller) writes:

|Not really... many disk packs I've seen clearly state "this program
|may not be disassembled..."

Not disassembled. Just read the code in like it's a dynamically loaded
library.

Sean
-- 
                  |``Wind, waves, etc. are breakdowns in the face of the
Sean Casey        | commitment to getting from here to there. But they are the
sean@s.ms.uky.edu | conditions for sailing -- not something to be gotten rid
U of KY, Lexington| of, but something to be danced with.''