z-buffer (was: to seam ...)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Tue, 23 Apr 1996 10:33:16 +0200 (MET DST)

From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Tue, 23 Apr 1996 10:33:16 +0200 (MET DST)
Message-Id: <199604230833.KAA06850@colossus.nero.uni-bonn.de>
To: quake-dev@gamers.org
Subject: z-buffer (was: to seam ...)

>From: "Brian K. Martin" <brian@phyast.pitt.edu>

>But I have to agree with you that it is hard to believe
>because I can never fill the z-buffer that fast.

The following as a quote from the Game Programming mailing list
at majordomo@inquo.net, from a recent posting by Scott C. Cottrille:

>And the interesting thing to note from Chris [Hecker]'s article is
>that he (and now id, I believe they borrowed Chris's code) has
>ordered and scheduled his texture mapper's inner loop instructions
>in such a way that the perspective division does not cost him any
>cycles. That is, he's not sitting there waiting for it to complete.
>He's using linear interpretation between everything 8th or 16th
>pixel, at which point he recalibrates by dividing. If you perform
>the initial 2 divisions outside the loop, then the inner division
>is for the next z value you will need. 7.5 texturing cycles/pixel

IIRC he refers to Chris Heckers perspective texture mapping article
series in the Game Developer Magazine, issues Apr/May to Aug/Sep 95
and Dec/Jan 96 - anybody happen to have access to these and could
confirm the claims above?

The point being: in this inner loop, you will have to increment
an offset into the z-buffer (one ADD), and to write the the 1/z
value already computed. I guess that, using float registers, you
have the integer register to spare. I do not do assembly, but from
a laymans point of view, this should be two cycles at least, or
approx. 25% overhead. To match that 15% claimed, it would have to
be less effectively. Hmm..

Of course, the really neat thing about this architecture is that
you do not have to clear the z-buffer.