Strip comments and inline ids onto h*

36-02.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: The Good, the Bad, and the Run-Sliced</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: The Good, the Bad, and the Run-Sliced</title>
   <meta name="chapter" content="36" />
   <meta name="pages" content="684-687" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -43,23 +36,20 @@
 
   <p>Take a moment to let the idea behind run-length slice drawing soak in. Periodic decisions must be made to control pixel placement. The key to speed is to make those decisions as infrequently and as quickly as possible. Of course, it will work to make a decision at each pixel&mdash;that&rsquo;s standard Bresenham&rsquo;s. However, most of those per-pixel decisions are redundant, and in fact we have enough information before we begin drawing to know which are the redundant decisions. Run-length slice drawing is exactly equivalent to standard Bresenham&rsquo;s, but it pares the decision-making process down to a minimum. It&rsquo;s somewhat analogous to the difference between finding the greatest common divisor of two numbers using Euclid&rsquo;s algorithm and finding it by trying every possible divisor. Both approaches produce the desired result, but that which takes maximum advantage of the available information and minimizes redundant work is preferable.</p>
 
-  <p><a id="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/36-02.jpg',409,190 )"> --><img src="images/36-02.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/36-02.jpg',409,190)"> --><b>Figure 36.2</b></a>&nbsp;&nbsp;<i>Run-length slice line drawing.</i></p>
+  <p><a id="Fig2"><img src="images/36-02.jpg" /><br />
+  <b>Figure 36.2</b></a>&nbsp;&nbsp;<i>Run-length slice line drawing.</i></p>
 
-  <p><a id="Fig3"><!-- </A><A HREF="javascript:displayWindow('images/36-03.jpg',414,198 )"> --><img src="images/36-03.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/36-03.jpg',414,198)"> --><b>Figure 36.3</b></a>&nbsp;&nbsp;<i>Runs in a slope 1/3.5 line.</i></p>
+  <p><a id="Fig3"><img src="images/36-03.jpg" /><br />
+  <b>Figure 36.3</b></a>&nbsp;&nbsp;<i>Runs in a slope 1/3.5 line.</i></p>
 
-  <h3><a id="Heading4"></a>Run-Length Slice Implementation</h3>
+  <h3 id="Heading4">Run-Length Slice Implementation</h3>
 
   <p>We know that for any line, a given run will always be one of two possible lengths. How, though, do we know which length to select? Surprisingly, this is easy to determine. For the following discussion, assume that we have a slope of 1/3.5, so that X is the major axis; however, the discussion also applies to Y-major lines, with X and Y reversed.</p>
 
   <p>The minimum possible length for any run in an X-major line is <b>int(XDelta/YDelta)</b>, where <b>XDelta</b> is the X-dimension of the line and <b>YDelta</b> is the Y-dimension. The maximum possible length is <b>int(XDelta/YDelta)+ 1</b>. The trick, then, is knowing which of these two lengths to select for each run. To see how we can make this selection, refer to Figure 36.4. For each one-pixel step along the minor axis (Y, in this case), we advance at least three pixels. The full advance distance along X (the major axis) is actually three-plus pixels, because there is also a fractional portion to the advance along X for a single-pixel Y step. This fractional advance is the key to deciding when to add an extra pixel to a run. The fraction indicates what portion of an extra pixel we advance along X (the major axis) during each run. If we keep a running sum of the fractional parts, we have a measure of how close we are to needing an extra pixel; when the fractional sum reaches 1, it&rsquo;s time to add an extra pixel to the current run. Then, we can subtract 1 from the running sum (because we just advanced one pixel), and continue on.</p>
 
-  <p><a id="Fig4"><!-- </A><A HREF="javascript:displayWindow('images/36-04.jpg',408,209 )"> --><img src="images/36-04.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/36-04.jpg',408,209)"> --><b>Figure 36.4</b></a>&nbsp;&nbsp;<i>How the error term determines run length.</i></p>
+  <p><a id="Fig4"><img src="images/36-04.jpg" /><br />
+  <b>Figure 36.4</b></a>&nbsp;&nbsp;<i>How the error term determines run length.</i></p>
 
   <p>Practically speaking, however, we can&rsquo;t work with fractions because floating-point arithmetic is slow and fixed-point arithmetic is imprecise. Therefore, we take a cue from standard Bresenham&rsquo;s and scale all the error-term calculations up so that we can work with integers. The fractional X (major axis) advance per one-pixel Y (minor axis) advance is the fractional portion of <b>XDelta/YDelta</b>. This value is exactly equivalent <b>to (XDelta % YDelta)/YDelta</b>. We&rsquo;ll scale this up by multiplying it by <b>YDelta*2</b>, so that the amount by which we adjust the error term up for each one-pixel minor-axis advance is <b>(XDelta % YDelta)*2</b>.</p>
 
@@ -86,10 +76,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>