Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=48//-->
|
||||
<!--PAGES=908-911//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -39,7 +39,7 @@
|
|||
<P>Listing 48.3 has an important limitation: It does not guarantee proper handling when the source and destination overlap, as in the case of a downward scroll, for example. Listing 48.3 performs top-to-bottom, left-to-right copying. Downward scrolls require bottom-to-top copying; likewise, rightward horizontal scrolls require right-to-left copying. As it happens, my intended use for Listing 48.3 is to copy images between off-screen memory and on-screen memory, and to save areas under pop-up menus and the like, so I don’t really need overlap handling—and I do really need to keep the complexity of this discussion down. However, you will surely want to add overlap handling if you plan to perform arbitrary scrolling and copying in display memory.
|
||||
</P>
|
||||
<P>Now that we have a fast way to copy images around in display memory, we can draw icons and other images as much as four times faster than in mode 13H, depending on the speed of the VGA’s display memory. (In case you’re worried about the nibble-alignment limitation on fast copies, don’t be; I’ll address that fully in due time, but the secret is to store all four possible rotations in off-screen memory, then select the correct one for each copy.) However, before our fast display memory-to-display memory copy routine can do us any good, we must have a way to get pixel patterns from system memory into display memory, so that they can then be copied with the fast copy routine.</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Copying to Display Memory</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A>Copying to Display Memory</H4>
|
||||
<P>The final piece of the puzzle is the system memory to display-memory-copy-routine shown in Listing 48.4. This routine assumes that pixels are stored in system memory in exactly the order in which they will ultimately appear on the screen; that is, in the same linear order that mode 13H uses. It would be more efficient to store all the pixels for one plane first, then all the pixels for the next plane, and so on for all four planes, because many <B>OUT</B>s could be avoided, but that would make images rather hard to create. And, while it is true that the speed of drawing images is, in general, often a critical performance factor, the speed of copying images from system memory to display memory is not particularly critical in Mode X. Important images can be stored in off-screen memory and copied to the screen via the latches much faster than even the speediest system memory-to-display memory copy routine could manage.</P>
|
||||
<P>I’m not going to present a routine to perform Mode X copies from display memory to system memory, but such a routine would be a straightforward inverse of Listing 48.4.</P>
|
||||
<P><B>LISTING 48.4 L48-4.ASM</B></P>
|
||||
|
|
@ -165,7 +165,7 @@ _CopySystemToScreenX endp
|
|||
end
|
||||
</PRE>
|
||||
<!-- END CODE //-->
|
||||
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">Who Was that Masked Image Copier?</FONT></H3>
|
||||
<H3><A NAME="Heading6"></A>Who Was that Masked Image Copier?</H3>
|
||||
<P>At this point, it’s getting to be time for us to take all the Mode X tools we’ve developed, together with one more tool—masked image copying—and the remaining unexplored feature of Mode X, page flipping, and build an animation application. I hope that when we’re done, you’ll agree with me that Mode X is <I>the</I> way to animate on the PC.</P>
|
||||
<P>In truth, though, it matters less whether or not <I>you</I> think that Mode X is the best way to animate than whether or not your users think it’s the best way based on results; end users care only about results, not how you produced them. For my writing, you folks are the end users—and notice how remarkably little you care about how this book gets written and produced. You care that it turned up in the bookstore, and you care about the contents, but you sure as heck don’t care about how it got that far from a bin of tree pulp. When you’re a creator, the process matters. When you’re a buyer, results are everything. All important. <I>Sine qua non.</I> The whole enchilada.</P>
|
||||
<P>If you catch my drift.</P><P><BR></P>
|
||||
|
|
@ -181,7 +181,7 @@ _CopySystemToScreenX endp
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue