Normal quotes

66-02.md

@@ -2,7 +2,7 @@
   [Previous](66-01.html)   [Table of Contents](index.html)   [Next](66-03.html)
   ------------------------ --------------------------------- --------------------
 
-As you may recall from Chapter 64, we’re concerned with both raw
+As you may recall from Chapter 64, we're concerned with both raw
 performance and level performance. That is, we want the drawing code to
 run as fast as possible, but we also want the difference in drawing
 speed between the average scene and the slowest-drawing scene to be as
@@ -24,7 +24,7 @@ overdrawn by nearer polygons. Raw performance in general was also
 reduced by the typical 50% overdraw resulting from drawing everything in
 the PVS. So, although drawing the PVS back-to-front as the final HSR
 stage worked and was an improvement over previous designs, it was not
-ideal. Surely, John thought, there’s a better way to leverage the PVS
+ideal. Surely, John thought, there's a better way to leverage the PVS
 than back-to-front drawing.
 
 And indeed there is.
@@ -49,7 +49,7 @@ this approach consists of turning each polygon into a set of spans, as
 shown in Figure 66.1, and then sorting and clipping the spans against
 each other until only the visible portions of visible spans are left to
 be drawn, as shown in Figure 66.2. This may sound a lot like z-buffering
-(which is simply too slow for use in drawing the world, although it’s
+(which is simply too slow for use in drawing the world, although it's
 fine for smaller moving objects, as described earlier), but there are
 crucial differences.
 
@@ -63,8 +63,8 @@ becomes a per-span operation with sorted spans, and because of the
 coherence implicit in a span list, each edge is sorted only against some
 of the spans on the same line and is clipped only to the few spans that
 it overlaps horizontally. Although complex scenes still take longer to
-process than simple scenes, the worst case isn’t as bad as with the beam
-tree or back-to-front approaches, because there’s no overdraw or
+process than simple scenes, the worst case isn't as bad as with the beam
+tree or back-to-front approaches, because there's no overdraw or
 scanning of hidden pixels, because complexity is limited to pixel
 resolution and because span coherence tends to limit the worst-case
 sorting in any one area of the screen. As a bonus, the output of sorted
@@ -72,24 +72,24 @@ spans is in precisely the form that a low-level rasterizer needs, a set
 of span descriptors, each consisting of a start coordinate and a length.
 
 In short, the sorted spans approach meets our original criteria pretty
-well; although it isn’t zero-cost, it’s not horribly expensive, it
+well; although it isn't zero-cost, it's not horribly expensive, it
 completely eliminates both overdraw and pixel scanning of obscured
 portions of polygons and it tends to level worst-case performance. We
-wouldn’t want to rely on sorted spans alone as our hidden-surface
+wouldn't want to rely on sorted spans alone as our hidden-surface
 mechanism, but the precalculated PVS reduces the number of polygons to a
 level that sorted spans can handle quite nicely.
 
-So we’ve found the approach we need; now it’s just a matter of writing
-some code and we’re on our way, right? Well, yes and no. Conceptually,
-the sorted-spans approach is simple, but it’s surprisingly difficult to
+So we've found the approach we need; now it's just a matter of writing
+some code and we're on our way, right? Well, yes and no. Conceptually,
+the sorted-spans approach is simple, but it's surprisingly difficult to
 implement, with a couple of major design choices to be made, a subtle
-mathematical element, and some tricky gotchas that I’ll have to defer
-until Chapter 67. Let’s look at the design choices first.
+mathematical element, and some tricky gotchas that I'll have to defer
+until Chapter 67. Let's look at the design choices first.
 
 ### Edges versus Spans {#Heading8}
 
 The first design choice is whether to sort spans or edges (both of which
-fall into the general category of “sorted spans”). Although the results
+fall into the general category of "sorted spans"). Although the results
 are the same both ways, a list of spans to be drawn, with no overdraw,
 the implementations and performance implications are quite different,
 because the sorting and clipping are performed using very different data