Replace invalid characters with HTML entities
— with — ’ with ’ + with + × with x ç with ç “ with “ ” with ” ‘ with ‘ • with • – with - µ with µ † with † Fix C++ θ with θ Yen symbol instead of times Fix broken apos Bullet again E-circumflex
This commit is contained in:
James Gregory
parent
9e52de9586
commit
500e7f5654
353 changed files with 5091 additions and 5091 deletions
30
39-02.html
30
39-02.html
|
|
@ -36,7 +36,7 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<P>At any rate, Listing 39.1 for this chapter shows a version of <B>DrawHorizontalLineList</B> that uses memset to draw each scan line of the polygon in a single call. When linked to Chapter 38’s test program, Listing 39.1 increases pure drawing speed (disregarding edge tracing and other nondrawing time) by more than an order of magnitude over Chapter 38’s draw-pixel-based code, despite the fact that Listing 39.1 requires a large (in this case, the Compact) data model. Listing 39.1 works fine with Borland C<SMALL>++</SMALL>, but may not work with other compilers, for it relies on the aforementioned interaction between memset and the selected memory model.</P>
|
||||
<P>At any rate, Listing 39.1 for this chapter shows a version of <B>DrawHorizontalLineList</B> that uses memset to draw each scan line of the polygon in a single call. When linked to Chapter 38’s test program, Listing 39.1 increases pure drawing speed (disregarding edge tracing and other nondrawing time) by more than an order of magnitude over Chapter 38’s draw-pixel-based code, despite the fact that Listing 39.1 requires a large (in this case, the Compact) data model. Listing 39.1 works fine with Borland C<SMALL>++</SMALL>, but may not work with other compilers, for it relies on the aforementioned interaction between memset and the selected memory model.</P>
|
||||
<TABLE WIDTH="100%"><TR>
|
||||
<TH COLSPAN="5"><HR>
|
||||
<TR>
|
||||
|
|
@ -94,7 +94,7 @@
|
|||
<TD VALIGN="TOP" ALIGN="LEFT">0.03<BR>(23%)
|
||||
<TD VALIGN="TOP" ALIGN="LEFT">0.03<BR>(23%)
|
||||
<TR>
|
||||
<TD VALIGN="TOP" ALIGN="LEFT" COLSPAN="5"><SMALL>All times are in seconds, as measured with Turbo Profiler on a 20-MHz cached 386 with no math coprocessor installed. Note that time spent in <B>main()</B> is not included. C code was compiled with Borland C<SMALL>++</SMALL> with maximum optimization (-G -O -Z -r -a); assembly language code was assembled with TASM. Percentages of combined times are rounded to the nearest percent, so the sum of the three percentages does not always equal 100.</SMALL>
|
||||
<TD VALIGN="TOP" ALIGN="LEFT" COLSPAN="5"><SMALL>All times are in seconds, as measured with Turbo Profiler on a 20-MHz cached 386 with no math coprocessor installed. Note that time spent in <B>main()</B> is not included. C code was compiled with Borland C<SMALL>++</SMALL> with maximum optimization (-G -O -Z -r -a); assembly language code was assembled with TASM. Percentages of combined times are rounded to the nearest percent, so the sum of the three percentages does not always equal 100.</SMALL>
|
||||
<TR>
|
||||
<TH COLSPAN="5"><HR>
|
||||
<TR>
|
||||
|
|
@ -107,18 +107,18 @@
|
|||
<!-- CODE //-->
|
||||
<PRE>
|
||||
/* Draws all pixels in the list of horizontal lines passed in, in
|
||||
mode 13h, the VGA’s 320×200 256-color mode. Uses memset to fill
|
||||
mode 13h, the VGA’s 320x200 256-color mode. Uses memset to fill
|
||||
each line, which is much faster than using DrawPixel but requires
|
||||
that a large data model (compact, large, or huge) be in use when
|
||||
running in real mode or 286 protected mode.
|
||||
All C code tested with Borland C++. */
|
||||
All C code tested with Borland C++. */
|
||||
|
||||
#include <string.h>
|
||||
#include <dos.h>
|
||||
#include “polygon.h”
|
||||
#include “polygon.h”
|
||||
|
||||
#define SCREEN_WIDTH 320
|
||||
#define SCREEN_SEGMENT 0×A000
|
||||
#define SCREEN_SEGMENT 0xA000
|
||||
|
||||
void DrawHorizontalLineList(struct HLineList * HLineListPtr,
|
||||
int Color)
|
||||
|
|
@ -139,21 +139,21 @@ void DrawHorizontalLineList(struct HLineList * HLineListPtr,
|
|||
Length = HLineListPtr->Length;
|
||||
while (Length-- > 0) {
|
||||
/* Draw the whole horizontal line if it has a positive width */
|
||||
if ((Width = HLinePtr->XEnd - HLinePtr->XStart + 1) > 0)
|
||||
memset(ScreenPtr + HLinePtr->XStart, Color, Width);
|
||||
HLinePtr++; /* point to next scan line X info */
|
||||
ScreenPtr += SCREEN_WIDTH; /* point to next scan line start */
|
||||
if ((Width = HLinePtr->XEnd - HLinePtr->XStart + 1) > 0)
|
||||
memset(ScreenPtr + HLinePtr->XStart, Color, Width);
|
||||
HLinePtr++; /* point to next scan line X info */
|
||||
ScreenPtr += SCREEN_WIDTH; /* point to next scan line start */
|
||||
}
|
||||
}
|
||||
</PRE>
|
||||
<!-- END CODE //-->
|
||||
<P>At this point, I’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’s logical to optimize the tracing code next.</P>
|
||||
<P>At this point, I’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’s logical to optimize the tracing code next.</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Fast Edge Tracing</FONT></H4>
|
||||
<P>There’s no secret as to why last chapter’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’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’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’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’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>
|
||||
<P>There’s no secret as to why last chapter’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’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’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’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’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>
|
||||
<TD WIDTH="5%" ALIGN="LEFT" VALIGN="TOP"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Floating point is very accurate—but it is not precise. Integer calculations, properly performed, are.</I></SMALL>
|
||||
<TD WIDTH="5%" ALIGN="LEFT" VALIGN="TOP"><IMG SRC="images/i.jpg"><TD WIDTH="95%" VALIGN="TOP" ALIGN="LEFT"><SMALL><I>Floating point is very accurate—but it is not precise. Integer calculations, properly performed, are.</I></SMALL>
|
||||
</TABLE>
|
||||
<P><BR></P>
|
||||
<CENTER>
|
||||
|
|
|
|||
Loading…
Reference in a new issue