Strip comments and inline ids onto h*

34-01.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: Changing Colors without Writing Pixels</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: Changing Colors without Writing Pixels</title>
   <meta name="chapter" content="34" />
   <meta name="pages" content="637-641" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -37,16 +30,16 @@
 
   <p><br /></p>
 
-  <h2><a id="Heading1"></a>Chapter 34<br />
+  <h2 id="Heading1">Chapter 34<br />
   Changing Colors without Writing Pixels</h2>
 
-  <h3><a id="Heading2"></a>Special Effects through Realtime Manipulation of DAC Colors</h3>
+  <h3 id="Heading2">Special Effects through Realtime Manipulation of DAC Colors</h3>
 
   <p>Sometimes, strange as it may seem, the harder you try, the less you accomplish. Brute force is fine when it suffices, but it does not always suffice, and when it does not, finesse and alternative approaches are called for. Such is the case with rapidly cycling through colors by repeatedly loading the VGA&rsquo;s Digital to Analog Converter (DAC). No matter how much you optimize your code, you just can&rsquo;t reliably load the whole DAC cleanly in a single frame, so you had best find other ways to use the DAC to cycle colors. What&rsquo;s more, BIOS support for DAC loading is so inconsistent that it&rsquo;s unusable for color cycling; direct loading through the I/O ports is the only way to go. We&rsquo;ll see why next, as we explore color cycling, and then finish up this chapter and this section by cleaning up some odds and ends about VGA color.</p>
 
   <p>There&rsquo;s a lot to be said about loading the DAC, so let&rsquo;s dive right in and see where the complications lie.</p>
 
-  <h3><a id="Heading3"></a>Color Cycling</h3>
+  <h3 id="Heading3">Color Cycling</h3>
 
   <p>As we&rsquo;ve learned in past chapters, the VGA&rsquo;s DAC contains 256 storage locations, each holding one 18-bit value representing an RGB color triplet organized as 6 bits per primary color. Each and every pixel generated by the VGA is fed into the DAC as an 8-bit value (refer to Chapter 33 and to Chapter A on the companion CD-ROM to see how pixels become 8-bit values in non-256 color modes) and each 8-bit value is used to look up one of the 256 values stored in the DAC. The looked-up value is then converted to analog red, green, and blue signals and sent to the monitor to form one pixel.</p>
 
@@ -56,7 +49,7 @@
 
   <p>Actually, so far as I know, you can&rsquo;t. At least you can&rsquo;t load the <i>entire</i> DAC&mdash;all 256 locations&mdash;frame after frame without producing distressing on-screen effects on at least some computers. In non-256 color modes, it is indeed possible to load the DAC quickly enough to cycle all displayed colors (of which there are 16 or fewer), so color cycling could be used successfully to cycle all colors in such modes. On the other hand, color paging (which flips among a number of color sets stored within the DAC in all modes other than 256 color mode, as discussed in Chapter A on the companion CD-ROM) can be used in non-256 color modes to produce many of the same effects as color cycling and is considerably simpler and more reliable then color cycling, so color paging is generally superior to color cycling whenever it&rsquo;s available. In short, color cycling is really the method of choice for dynamic color effects only in 256-color mode&mdash;but, regrettably, color cycling is at its least reliable and capable in that mode, as we&rsquo;ll see next.</p>
 
-  <h3><a id="Heading4"></a>The Heart of the Problem</h3>
+  <h3 id="Heading4">The Heart of the Problem</h3>
 
   <p>Here&rsquo;s the problem with loading the entire DAC repeatedly: The DAC contains 256 color storage locations, each loaded via either 3 or 4 <b>OUT</b> instructions (more on that next), so at least 768 <b>OUT</b>s are needed to load the entire DAC. That many <b>OUT</b>s take a considerable amount of time, all the more so because <b>OUT</b>s are painfully slow on 486s and Pentiums, and because the DAC is frequently on the ISA bus (although VLB and PCI are increasingly common), where wait states are inserted in fast computers. In an 8 MHz AT, 768 <b>OUT</b>s alone would take 288 microseconds, and the data loading and looping that are also required would take in the ballpark of 1,800 microseconds more, for a minimum of 2 milliseconds total.</p>
 
@@ -83,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>