Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

12
45-02.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=45//-->
<!--PAGES=843-846//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -90,16 +90,16 @@
<P>For graphics, this especially means using write mode 3 rather than the bit-mask register. When you must use the bit mask, arrange drawing so that you can set the bit mask once, then do a lot of drawing with that mask. For example, draw a whole edge at once, then the middle, then the other edge, rather than setting the bit mask several times on each scan line to draw the edge and middle bytes together. Don&rsquo;t read from display memory if you don&rsquo;t have to. Write each pixel once and only once.
</P>
<P>It is indeed a strange concept: The key to fast graphics is staying away from the graphics adapter as much as possible.</P>
<H3><A NAME="Heading5"></A><FONT COLOR="#000077">Dirty-Rectangle Animation</FONT></H3>
<H3><A NAME="Heading5"></A>Dirty-Rectangle Animation</H3>
<P>The relative slowness of VGA hardware is part of the appeal of the technique that I call &ldquo;dirty-rectangle&rdquo; animation, in which a complete copy of the contents of display memory is maintained in offscreen system (nondisplay) memory. All drawing is done to this system buffer. As offscreen drawing is done, a list is maintained of the bounding rectangles for the drawn-to areas; these are the <I>dirty rectangles</I>, &ldquo;dirty&rdquo; in the sense that that have been altered and no longer match the contents of the screen. After all drawing for a frame is completed, all the dirty rectangles for that frame are copied to the screen in a burst, and then the cycle of off-screen drawing begins again.</P>
<P>Why, exactly, would we want to go through all this complication, rather than simply drawing to the screen in the first place? The reason is visual quality. If we were to do all our drawing directly to the screen, there&rsquo;d be a lot of flicker as objects were erased and then redrawn. Similarly, overlapped drawing done with the painter&rsquo;s algorithm (in which farther objects are drawn first, so that nearer objects obscure them) would flicker as farther objects were visible for short periods. With dirty-rectangle animation, only the finished pixels for any given frame ever appear on the screen; intermediate results are never visible. Figure 45.1 illustrates the visual problems associated with drawing directly to the screen; Figure 45.2 shows how dirty-rectangle animation solves these problems.</P>
<P><A NAME="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/45-01.jpg',409,160 )"> --><IMG SRC="images/45-01.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/45-01.jpg',409,160)"> --><FONT COLOR="#000077"><B>Figure 45.1</B></FONT></A>&nbsp;&nbsp;<I>Drawing directly to the screen.</I>
<BR><A HREF="javascript:displayWindow('images/45-01.jpg',409,160)"> --><B>Figure 45.1</B></A>&nbsp;&nbsp;<I>Drawing directly to the screen.</I>
</P>
<P><A NAME="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/45-02.jpg',411,301 )"> --><IMG SRC="images/45-02.jpg"><BR><!-- </A>
<BR><A HREF="javascript:displayWindow('images/45-02.jpg',411,301)"> --><FONT COLOR="#000077"><B>Figure 45.2</B></FONT></A>&nbsp;&nbsp;<I>Dirty rectangle animation.</I>
<BR><A HREF="javascript:displayWindow('images/45-02.jpg',411,301)"> --><B>Figure 45.2</B></A>&nbsp;&nbsp;<I>Dirty rectangle animation.</I>
</P>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">So Why Not Use Page Flipping?</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading6"></A>So Why Not Use Page Flipping?</H4>
<P>Well, then, if we want good visual quality, why not use page flipping? For one thing, not all adapters and all modes support page flipping. The CGA and MCGA don&rsquo;t, and neither do the VGA&rsquo;s 640x480 16-color or 320x200 256-color modes, or many SuperVGA modes. In contrast, <I>all</I> adapters support dirty-rectangle animation. Another advantage of dirty-rectangle animation is that it&rsquo;s generally faster. While it may seem strange that it would be faster to draw off-screen and then copy the result to the screen, that is often the case, because dirty-rectangle animation usually reduces the number of times the VGA&rsquo;s hardware needs to be touched, especially in 256-color modes.</P>
<P>This reduction comes about because when dirty rectangles are erased, it&rsquo;s done in system memory, not in display memory, and since most objects move a good deal less than their full width (that is, the new and old positions overlap), display memory is written to fewer times than with page flipping. (In 16-color modes, this is not necessarily the case, because of the parallelism obtained from the VGA&rsquo;s planar hardware.) Also, read/modify/write operations are performed in fast system memory rather than slow display memory, so display memory rarely needs to be read. This is particularly good because display memory is generally even slower for reads than for writes.</P><P><BR></P>
<CENTER>
@ -114,7 +114,7 @@
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->