Strip comments and inline ids onto h*

63-04.html

@@ -10,16 +10,9 @@
   <meta name="vspubdate" content="07/01/97" />
   <meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
 
-  <title>Michael Abrash's Graphics Programming Black Book Special Edition: Floating-Point for Real-Time 3-D</title><!-- HEADER -->
-  <!-- Empty Reference Subhead -->
-  <!--ISBN=1576101746//-->
-  <!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
-  <!--AUTHOR=Michael Abrash//-->
-  <!--PUBLISHER=The Coriolis Group, Inc.//-->
+  <title>Michael Abrash's Graphics Programming Black Book Special Edition: Floating-Point for Real-Time 3-D</title>
   <meta name="chapter" content="63" />
   <meta name="pages" content="1173-1175" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -41,7 +34,7 @@
 
   <p>When fully interleaved, however, only a single cycle is lost (again to the extra cycle of FST latency), and the cycle count drops to 34, as shown in Listing 63.6. This means that on a 100 MHz Pentium, it&rsquo;s theoretically possible to do nearly 3,000,000 transforms per second, although that&rsquo;s a purely hypothetical number, due to cache effects and set-up costs. Still, more than 1,000,000 transforms per second is certainly feasible; at a frame rate of 30 Hz, that&rsquo;s an impressive 30,000 transforms per frame.</p>
 
-  <p><b>Listing 63.6 L63-6.ASM</b></p><!-- CODE //-->
+  <p><b>Listing 63.6 L63-6.ASM</b></p>
   <pre>
 ;optimized transformation: 34 cycles
       fld      [vec0+0]           ;starts &amp; ends on cycle 0
@@ -83,21 +76,21 @@
                                   ; ends on cycle 31
       fstp     [vec1+4]           ;starts on cycle 32,
                                   ; ends on cycle 33
-</pre><!-- END CODE //-->
+</pre>
 
-  <h3><a id="Heading10"></a>Projection</h3>
+  <h3 id="Heading10">Projection</h3>
 
   <p>The final optimization we&rsquo;ll look at is projection to screenspace. Projection itself is basically nothing more than a divide (to get 1/z), followed by two multiplies (to get x/z and y/z), so there wouldn&rsquo;t seem to be much in the way of FP optimization possibilities there. However, remember that although FDIV has a latency of up to 39 cycles, it can overlap with integer instructions for all but one of those cycles. That means that if we can find enough independent integer work to do before we need the 1/z result, we can effectively reduce the cost of the FDIV to one cycle. Projection by itself doesn&rsquo;t offer much with which to overlap, but other work such as clamping, window-relative adjustments, or 2-D clipping could be interleaved with the FDIV for the next point.</p>
 
   <p>Another dramatic speed-up is possible by setting the precision of the FPU down to single precision via FLDCW, thereby cutting the time FDIV takes to a mere 19 cycles. I don&rsquo;t have the space to discuss reduced precision in detail in this book, but be aware that along with potentially greater performance, it carries certain risks, as well. The reduced precision, which affects FADD, FSUB, FMUL, FDIV, and FSQRT, can cause subtle differences from the results you&rsquo;d get using compiler defaults. If you use reduced precision, you should be on the alert for precision-related problems, such as clipped values that vary more than you&rsquo;d expect from the precise clip point, or the need for using larger epsilons in comparisons for point-on-plane tests.</p>
 
-  <h3><a id="Heading11"></a>Rounding Control</h3>
+  <h3 id="Heading11">Rounding Control</h3>
 
   <p>Another useful area that I can note only in passing here is that of leaving the FPU in a particular rounding mode while performing bulk operations of some sort. For example, conversion to int via the FIST instruction requires that the FPU be in chop mode. Unfortunately, the FLDCW instruction must be used to get the FPU into and out of chop mode, and each FLDCW takes 7 cycles, meaning that compilers often take at least 14 cycles for each float-&gt;int conversion. In assembly, you can just set the rounding state (or, likewise, the precision, for faster FDIVs) once at the start of the loop, and save all those FLDCW cycles each time through the loop. This is even more true for <b>ceil()</b>, which many compilers implement as horrendously inefficient subroutines, even though there are rounding modes for both <b>ceil()</b> and <b>floor()</b>. Again, though, be aware that results of FP calculations will be subtly different from compiler default behavior while chop, ceil, or floor mode is in effect.</p>
 
   <p>A final note: There are some speed-ups to be had by manipulating FP variables with integer instructions. Check out Chris Hecker&rsquo;s column in the February/March 1996 issue of <i>Game Developer</i> for details.</p>
 
-  <h3><a id="Heading12"></a>A Farewell to 3-D Fixed-Point</h3>
+  <h3 id="Heading12">A Farewell to 3-D Fixed-Point</h3>
 
   <p>As with most optimizations, there are both benefits and hazards to floating-point acceleration, especially pedal-to-the-metal optimizations such as the last few I&rsquo;ve mentioned. Nonetheless, I&rsquo;ve found floating-point to be generally both more robust and easier to use than fixed-point even with those maximum optimizations. Now that floating-point is fast enough for real time, I don&rsquo;t expect to be doing a whole lot of fixed-point 3-D math from here on out.</p>
 
@@ -120,10 +113,6 @@
 
   <div align="center">
     Graphics Programming Black Book &copy; 2001 Michael Abrash
-  </div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
-  <!-- reference_subfoot = footer -->
-  <!-- reference_footer = subfoot -->
-  <!-- BEGIN SUB FOOTER -->
-  <!-- END FOOTER -->
+  </div>
 </body>
 </html>