From: Dave Stampe-Psy+Eng <[email-masked]>
Date: Tue, 22 Oct 91 01:22:52 -0400

Lance replied to a lot of my postings, so instead of a lot of little
postings, I'll try to handle them in one loner one:

From: Lance Norskog <[email-masked]>

>Dave Stamp says:
>
>> I think I see the problem here.  The difference is between the IBM and Amiga
>> designs.  Any real graphics work on the IBM PC requires multiple I/O space
>> accesses with inportb() and ouportb() type routines.  Since most of the 
>> available C compilers do not replace these with inline code, this results
>> in much slower operation than with assembly code.  Also, many of the good 
>> instructions on the 80x86 (such as LOOP or REP STOSB) are not used by 
>> compilers.  Again, assembly code is the only solution.  
	
>Nope!  The IBM PC bus was designed to be cheap, and support text.
>It was not designed with NTSC video bandwidth in mind, while the
>Amiga was.  The hardware is at fault, not the software.  

I was referring to programming style as dictated _by_ the hardware, not the
hardware per se.

>The PC VR software is going to have use scan-line techniques, or
>paint in real RAM and copy that into the VGA frame buffer.  Multiple
>touches of the same pixel would be the kiss of death.

Exactly what I plan to do: use scan-line algorithms.  They have a big 
advantage over other methods in that they write each pixel once and
degrade gracefully with increasing numbers of polys.  The amount of 
optimization possible is pretty awesome.  Also, since you're drawing
each poly once, Gourand shading and texture mapping become less expensive.

Copying a buffer to the VGA card wastes more time than it saves unless
you're doing really wierd things that require multiple accesses to each pixel.
In this case, it's not warranted. 

>Actually, the 8514/A clone cards are appearing mass-market for $500
>from Western Digital etc.  These things include a raft of 2D graphics
>commands which you just poke at it and go away.

There are a couple of problems with the 8514/A cards.  First, using new
hardware violates the cheapness constraint on the system: less people
can get involved.  Second, as you pointed out, flexibility is less:
video modes can't be chosen easily.  Third, when you consider the time
used up stuffing the command FIFO versus the draw time, the performance
advantage for a scan-line renderer is pretty low, as you're just drawing
horizontal line segments.  Of course, if you're doing wireframe...
 
<in reference to my clipping message, which proposes a drawing rate
of >300 polys in 100 mS... or was it my database size of 10,000 polys?>

>I think you're off by an order or two of magnitude.
>But I have no hard numbers.

No, that's the beauty of the algorithm I'm working on!  I should get 
AT LEAST 200 polys per rendering cycle, and if I use 320x200x16 mode,
it takes about 50 mS-- plenty of time for the poly database processing.
I'm off by AT MOST a factor of 2.

>You should also consider that background walls and floors can be done
>by pre-rendering them onto pixmaps, then resampling the pixmaps
>onto the screen first.  Then, start drawing your wire-frames or
>filled polygons.

Yes, it is a possibility, IF you're using textures.  But this requires
"touching" each pixel twice...  Perhaps these areas could be copied out
of a buffer by the scan-line renderer where no polys cover.

>Again, check out BSP in the Computer Graphics book, and
>the ASP in Graphics Interface '90.  These are the front-runners
>for repetitive polygonal database update methods.

I have checked out these methods and, IMHO, they are not as useful 
as they appear.  They are best used to depth-sort polys for schemes
that draw ALL the polys over and over again.  They can help with object-
level rejection in the "front end" of the renderer, but no further.
The keyword is "repetitive" and we can't afford that on this machine.
I suspect even the Amiga starts getting into problems, as drawing a
poly takes significant CPU intervention to keep the hardware fed with
all those horizontal line commands that the Amiga's hardware supports.
Plus, as soon as you go to Gourand shading or texture mapping, it all
has to be done by the CPU anyway.

< a comment on the proposed glove interface >

>A tip: it will be much easier to get this stuff working right if
>you encode the whole process, both hi-res-mode-init and the
>polling loop, into a finite state machine.  Your TSR can then
>just do a case statement to decide what to do.  It's a little
>tougher to code than by hand, but it's the only way to fly
>in an interrupt-driven environment.

This isn't TSR code though: nor is it a device driver.  This is to be linked 
into a C program.  There really IS only one path through interrupts, with
early termination if the glove isn't ready yet.  I don't understand _why_
a state machine should be tougher-- it's just an implementation decision
after all.

Thanks for the feedback.  Can you please include at least the gist of the
original message?  I had trouble figuring out which one you were replying
to.  Ahh, the perils of asynchrony (B_{).

--------------------------------------------------------------------------
| My life is Hardware,                    |                              | 
| my destiny is Software,                 |         Dave Stampe          |
| my CPU is Wetware...                    |                              | 
| Anybody got a SDB I can borrow?         | [email-masked] |
__________________________________________________________________________