From: dstamp@watserv1.waterloo.edu (Dave Stampe-Psy+Eng)
Subject: Re: VR: Low-End 3D -- Big in U.K., Why Not the U.S.?
Date: Tue, 15 Oct 1991 17:22:44 GMT
Message-ID: <1991Oct15.172244.29481@watserv1.waterloo.edu>
Organization: University of Waterloo



In article <1991Oct14.185644.26057@milton.u.washington.edu> MBS110@psuvm.psu.
edu (Norman St. John Polevaulter) writes:

>In article <1991Oct14.034241.11786@milton.u.washington.edu>,
>trpw@cix.compulink.co.uk (Tim Watson) says:
>
>>        A few years back I was involved in writing some 3D software for the
>>        PC and on a good day my program could splat about 1000 shaded
>>        polygons per second on the screen of a 25Mhz 386. This program went
>>        on to form the basis of Argonaut Software's game Starglider 2. Jez
>>        San (of whom you may have heard), the head of Argonaut Software, says
>>        (and I've no reason to doubt him) that the routines have been vastly
>>        improved since I left Argonaut. In the past few years I have seen
>>        programs from at least five companies or individuals which overshadow
>>        my efforts.
>>
>You want more people to write 3D graphics in assembly? Ring up Jez San, David
>Braben and all the other people you mentioned and ask them to help by
>describing just how it's done! As long as everyone who figures it out keeps
>it to themselves, 3D programming is going to move very, very slowly.
>It's sad to think of how many VR-type games we'd have by now if this
>information was freely available.

I think a good start to the programming is to swap ideas.  I have some ideas
about fast poly drawing, but I would like to see the opinions of other
people to develop them further.  Any input is helpful, even info about
a rather "klunky" implementation.

When I was writing graphics software on the 6809, some of my best code came
from reverse-engineering other writer's software and seeing how their ideas
could be improved.  Reverse-engineering is quite ethical, as long as you
don't use any of the code directly in your software.  The only problem with
it is the time it takes.  I've been working on the PC for 3 years now,
and it took me this long to get comfortable enough to speed through other's
EXE files.

I would like your feedback to these ideas:

- Phong shaded versus solid polygons: Phong shading *can* be done with the
cost of 40% extra time--BUT is it really needed for cheap VR?  Solid polys
are real enough, and can use 16-color instead of 256-color modes

- Monochrome versus color: Most cheap VR systems will use monochrome 
 LCDs anyway, and using monochrome simplifies calculations.  Also, this
will make 16 color display modes practical.

- Full polygons versus triangles: Triangles are easy to sort, clip, and
mask (by splitting).  Any polygon may be implemented with triangles

-Implementation: My idea goes like this: Trasnslate all XYZ points
(corners of triangles) to xyz (perspective plane x,y,depth) and sort
by depth.  Starting at the closest, find all that fall within the tri's
depth, and also xy area.  Then either:

-break all into horizontal line segments, find ovrlays and fill OR

-break each lower tri in smaller tri's, based on the masking by the
frontmost tri, and reinsert in the depth list

THEN fill each tri by breaking int upper/lower boundry sets and doing
line fills (use Bresenham technique to compute line ends).

FOR PHONG, compute the shade value for each end of the line to fill,
then use an increment-with-underflow to step the shading along the line
as it is filled (works for monochrome only).

One problem with PC's is the slow access time of the graphics cards.
The fastest I've seen is about 500nS per access, which can cut down speed 
a lot.  This has to be considered when figuring line-fill speed.

My speed calculations based on line-fill code segments, 20x20 tri's, a 486/25
and estimating setup code is:

PHONG, 256 color: 800 uS per tri, 1500 tri/sec
SOLID, 256 color: 400 uS per tri, 3000 tri/sec
SOLID, 16 color : 200 uS per tri, 5000 tri/sec

These are all estimates, of course.  Poly sorting time, clipping and
3D transforms are not included, as the floting point on the 486 is very fast
(I estimate 50uS per point) 
 
Any comments, criticisms, etc??  I don't have time to write this code myself,
but as an ex-highspeed graphics hack, I'd be glad to help.

If wanted, I can supply the code segnebts I used and clock-cycle estimates.

-Dave Stampe