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

6
39-02.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=39//-->
<!--PAGES=727-730//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -149,7 +149,7 @@ void DrawHorizontalLineList(struct HLineList * HLineListPtr,
<!-- END CODE //-->
<P>At this point, I&rsquo;d like to mention that benchmarks are notoriously unreliable; the results in Table 39.1 are accurate <I>only</I> for the test program, and only when running on a particular system. Results could be vastly different if smaller, larger, or more complex polygons were drawn, or if a faster or slower computer/VGA combination were used. These factors notwithstanding, the test program does fill a variety of polygons of varying complexity sized from large to small and in between, and certainly the order of magnitude difference between Listing 39.1 and the old version of <B>DrawHorizontalLineList</B> is a clear indication of which code is superior.</P>
<P>Anyway, Listing 39.1 has the desired effect of vastly improving drawing time. There are cycles yet to be had in the drawing code, but as tracing polygon edges now takes 92 percent of the polygon filling time, it&rsquo;s logical to optimize the tracing code next.</P>
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Fast Edge Tracing</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading5"></A>Fast Edge Tracing</H4>
<P>There&rsquo;s no secret as to why last chapter&rsquo;s <B>ScanEdge</B> was so slow: It used floating point calculations. One secret of fast graphics is using integer or fixed-point calculations, instead. (Sure, the floating point code would run faster if a math coprocessor were installed, but it would still be slower than the alternatives; besides, why require a math coprocessor when you don&rsquo;t have to?) Both integer and fixed-point calculations are fast. In many cases, fixed-point is faster, but integer calculations have one tremendous virtue: They&rsquo;re completely accurate. The tiny imprecision inherent in either fixed or floating-point calculations can result in occasional pixels being one position off from their proper location. This is no great tragedy, but after going to so much trouble to ensure that polygons don&rsquo;t overlap at common edges, why not get it exactly right?</P>
<P>In fact, when I tested out the integer edge tracing code by comparing an integer-based test image to one produced by floating-point calculations, two pixels out of the whole screen differed, leading me to suspect a bug in the integer code. It turned out, however, that&rsquo;s in those two cases, the floating point results were sufficiently imprecise to creep from just under an integer value to just over it, so that the <B>ceil</B> function returned a coordinate that was one too large.</P>
<TABLE WIDTH="100%"><TR>
@ -168,7 +168,7 @@ void DrawHorizontalLineList(struct HLineList * HLineListPtr,
<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 -->