🚀 go-pugleaf

Hey, let's all take some time away from the TP vs. C++  discussion 
to look at this message (a welcom diversion I should think)

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.

I've been working on various routines to try and duplicate a lot of
what these systems have to offer (in assembly- not TP or C++, though
I call 'em from C++). Anyway, there are a lot of simple routines that
make up this impressive(?) system.

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

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.

Anway, I'd like feedback on what others think about how the basic 
system works. In particular, given a cube shaped object, just how
many bitmaps/views of it do you think they store (assume no reflection
can be done). Also, it's obvious that they have some good rotation
code for the bitmaps- but do you think there is any other 'massaging' done
to, say, generate multiple bitmaps from a single source?

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!


Mike