Normal quotes

39-02.md

@@ -4,10 +4,10 @@
 
 At any rate, Listing 39.1 for this chapter shows a version of
 **DrawHorizontalLineList** that uses memset to draw each scan line of
-the polygon in a single call. When linked to Chapter 38’s test program,
+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
+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++, but may not work with other compilers, for it relies
 on the aforementioned interaction between memset and the selected memory
@@ -145,7 +145,7 @@ Table 39.1 Polygon fill performance.
 **LISTING 39.1 L39-1.C**
 
     /* Draws all pixels in the list of horizontal lines passed in, in
-       mode 13h, the VGA’s 320x200 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.
@@ -153,7 +153,7 @@ Table 39.1 Polygon fill performance.
 
     #include <string.h>
     #include <dos.h>
-    #include “polygon.h”
+    #include "polygon.h"
 
     #define SCREEN_WIDTH    320
     #define SCREEN_SEGMENT  0xA000
@@ -184,7 +184,7 @@ Table 39.1 Polygon fill performance.
        }
     }
 
-At this point, I’d like to mention that benchmarks are notoriously
+At this point, I'd like to mention that benchmarks are notoriously
 unreliable; the results in Table 39.1 are accurate *only* 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
@@ -197,29 +197,29 @@ which code is superior.
 
 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
+polygon edges now takes 92 percent of the polygon filling time, it's
 logical to optimize the tracing code next.
 
 #### Fast Edge Tracing {#Heading5}
 
-There’s no secret as to why last chapter’s **ScanEdge** was so slow: It
+There's no secret as to why last chapter's **ScanEdge** 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
+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.
+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
+much trouble to ensure that polygons don't overlap at common edges, why
 not get it exactly right?
 
 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,
+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 **ceil**
 function returned a coordinate that was one too large.