🚀 go-pugleaf

I'd better clarify a few things here.  While I'm not sure of everything about
the demo, I have had a few Turbo Debugger sessions with it (remote of course),
and can offer the following:

>> 	A few friends an I have been drooling over the latest release of the
>> Unreal demo that Future Crew, as well as their release of the Fishtro Demo.
>> And quite frankly, these guys are impressive.
> 
> No need to get your shirt wet, UNREAL isn't as impressive as it first seems...

Quite true.

> a FLI/FLC format (or possibly their own internal format).  The "speed" is
For some of the things.  For instance, the FC that flies through on the
Something part is stored in a file called ANIM.FCA that is about 140k.  Just a
bunch of blits.

>> What I would like to know is how the hell the can do the World Vector part
>> of the demo.  Its the rotation see, that gets me.  Sure, sure there are 
>> algorithms evvery where that can rotate.  No problem there
> 
> I believe the World Vector part was the terrain of single pixels, right?

No, that was landscape.  The techniques been around for years.  It was
fractally generated terrain, only stored in a buffer and not mapped right next
to each other.  Lay you odds if all of the pixels were put next to each other
that it would be smaller than a 320x200 screen.

The World Vector part is actually just a bunch of 3d rotations.  It was
programmed for a 386 which means that 32-bit registers can be used...in other
words, fixed-point numbers.

>> 1.) Does one rotate all points or is there a spify alogrithm that can do
>> them all real quick based on one rotation.

A Bresenham line routine would do it.  The angles the same for everything
(assuming you are still talking about the Landscape part).  Just map along the
line, adjusting the pixel height based on color.

> You'd only need to rotate the points that are within the "square" that is
> currently viewable.  If your square area is only about 50x50 points, you
> can rotate them *very* quickly in real time.  You can also use fixed point
> instead of floating point... this'll give you a speed increase (unless you're
> using a co-pro).

Again, I don't know if Future Crew used the Bresenham line technique, but that
eliminates all but two sin, cosine calculations...to figure out the slope of
the line.  One you have the slope, you invert it and have the perpendicular. 
Thus you have all things necessary tomap the pixels.

>> 3.) How do they (or any one else) determine the shading for the different
>> polyogns based on a light source.

I didn't notice that.  I'll have to go back and look.

Joshua Jensen