Strip comments and inline ids onto h*
This commit is contained in:
James Gregory
parent
1997a7846d
commit
0f5f617adb
362 changed files with 2519 additions and 6694 deletions
31
44-04.html
31
44-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: Split Screens Save the Page Flipped Day</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: Split Screens Save the Page Flipped Day</title>
|
||||
<meta name="chapter" content="44" />
|
||||
<meta name="pages" content="830-833" />
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//-->
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
|
@ -39,7 +32,7 @@
|
|||
|
||||
<p>Listing 44.1 is written in C. It could equally well have been written in assembly language, and would then have been somewhat faster. However, wanted to make the point (as I’ve made again and again) that assembly language, and, indeed, optimization in general, is needed only in the most critical portions of any program, and then only when the program would otherwise be too slow. Only in a highly performance-sensitive situation would the performance boost resulting from converting Listing 44.1 to assembly justify the time spent in coding and the bugs that would likely creep in—and the sample program already updates the screen at the maximum possible rate of once per frame even on a 1985-vintage 8-MHz AT. In this case, faster performance would result only in a longer wait for the page to flip.</p>
|
||||
|
||||
<h4 align="center"><a id="Heading5"></a>Write Mode 3</h4>
|
||||
<h4 align="center" id="Heading5">Write Mode 3</h4>
|
||||
|
||||
<p>It’s possible to update the bitmap very efficiently on the VGA, because the VGA can draw up to 8 pixels at once, and because the VGA provides a number of hardware features to speed up drawing. This article makes considerable use of one particularly unusual hardware feature, write mode 3. We discussed write mode 3 back in Chapter 26, but we’ve covered a lot of ground since then—so I’m going to run through a quick refresher on write mode 3.</p>
|
||||
|
||||
|
|
@ -49,32 +42,32 @@
|
|||
|
||||
<p>Write mode 3 is useful when you want to set some but not all of the pixels in a single byte of display memory <i>to the same color.</i> That is, if you want to draw a number of pixels within a byte in a single color, write mode 3 is a good way to do it.</p>
|
||||
|
||||
<p>Write mode 3 works like this. First, set the Graphics Controller Mode register to write mode 3. (Look at Listing 44.2 for code that does everything described here.) Next, set the Set/Reset register to the color with which you wish to draw, in the range 0-15. (It is not necessary to explicitly enable set/reset via the Enable Set/Reset register; write mode 3 does that automatically.) Then, to draw individual pixels within a single byte, simply read display memory, and then write a byte to display memory with 1-bits where you want the color to be drawn and 0-bits where you want the current bitmap contents to be preserved. (Note well that <i>the data actually read by the CPU doesn’t matter;</i> the read operation latches all four planes’ data, as described way back in Chapter 24.) So, for example, if write mode 3 is enabled and the Set/Reset register is set to 1 (blue), then the following sequence of operations:</p><!-- CODE SNIP //-->
|
||||
<p>Write mode 3 works like this. First, set the Graphics Controller Mode register to write mode 3. (Look at Listing 44.2 for code that does everything described here.) Next, set the Set/Reset register to the color with which you wish to draw, in the range 0-15. (It is not necessary to explicitly enable set/reset via the Enable Set/Reset register; write mode 3 does that automatically.) Then, to draw individual pixels within a single byte, simply read display memory, and then write a byte to display memory with 1-bits where you want the color to be drawn and 0-bits where you want the current bitmap contents to be preserved. (Note well that <i>the data actually read by the CPU doesn’t matter;</i> the read operation latches all four planes’ data, as described way back in Chapter 24.) So, for example, if write mode 3 is enabled and the Set/Reset register is set to 1 (blue), then the following sequence of operations:</p>
|
||||
<pre>
|
||||
mov dx,0a000h
|
||||
mov es,dx
|
||||
mov al,es:[0]
|
||||
mov byte ptr es:[0],0f0h
|
||||
</pre><!-- END CODE SNIP //-->
|
||||
</pre>
|
||||
|
||||
<p>will change the first 4 pixels on the screen (the left nibble of the byte at offset 0 in display memory) to blue, and will leave the next 4 pixels (the right nibble of the byte at offset 0) unchanged.</p>
|
||||
|
||||
<p>Using one <b>MOV</b> to read from display memory and another to write to display memory is not particularly efficient on some processors. In Listing 44.2, I instead use <b>XCHG</b>, which reads and then writes a memory location in a single operation, as in:</p><!-- CODE SNIP //-->
|
||||
<p>Using one <b>MOV</b> to read from display memory and another to write to display memory is not particularly efficient on some processors. In Listing 44.2, I instead use <b>XCHG</b>, which reads and then writes a memory location in a single operation, as in:</p>
|
||||
<pre>
|
||||
mov dx,0a000h
|
||||
mov es,dx
|
||||
mov al,0f0h
|
||||
xchg es:[0],al
|
||||
</pre><!-- END CODE SNIP //-->
|
||||
</pre>
|
||||
|
||||
<p>Again, the actual value that’s read is irrelevant. In general, the <b>XCHG</b> approach is more compact than two <b>MOV</b>s, and is faster on 386 and earlier processors, but slower on 486s and Pentiums.</p>
|
||||
|
||||
<p>If all pixels in a byte of display memory are to be drawn in a single color, it’s not necessary to read before writing, because none of the information in display memory at that byte needs to be preserved; a simple write of 0FFH (to draw all bits) will set all 8 pixels to the set/reset color:</p><!-- CODE SNIP //-->
|
||||
<p>If all pixels in a byte of display memory are to be drawn in a single color, it’s not necessary to read before writing, because none of the information in display memory at that byte needs to be preserved; a simple write of 0FFH (to draw all bits) will set all 8 pixels to the set/reset color:</p>
|
||||
<pre>
|
||||
mov dx,0a000h
|
||||
mov es,dx
|
||||
mov byte ptr es:[di],0ffh
|
||||
</pre><!-- END CODE SNIP //-->
|
||||
</pre>
|
||||
|
||||
<table width="100%">
|
||||
<tr>
|
||||
|
|
@ -86,7 +79,7 @@ mov byte ptr es:[di],0ffh
|
|||
|
||||
<p>In short, write mode 3 is a good choice for single-color drawing that modifies individual pixels within display memory bytes. Not coincidentally, the sample application draws only single-color objects within the animation area; this allows write mode 3 to be used for all drawing, in keeping with our desire for speedy screen updates.</p>
|
||||
|
||||
<h4 align="center"><a id="Heading6"></a>Drawing Text</h4>
|
||||
<h4 align="center" id="Heading6">Drawing Text</h4>
|
||||
|
||||
<p>We’ll need text in the sample application; is that also a good use for write mode 3? Sometimes it is, but not in this particular case.</p>
|
||||
|
||||
|
|
@ -109,10 +102,6 @@ mov byte ptr es:[di],0ffh
|
|||
|
||||
<div align="center">
|
||||
Graphics Programming Black Book © 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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue