Normal quotes

64-03.md

@@ -4,7 +4,7 @@
 
 ### The Beam Tree {#Heading8}
 
-John’s original Quake design was to draw front-to-back, using a second
+John's original Quake design was to draw front-to-back, using a second
 BSP tree to keep track of what parts of the screen were already drawn
 and which were still empty and therefore drawable by the remaining
 polygons. Logically, you can think of this BSP tree as being a 2-D
@@ -14,7 +14,7 @@ tree.* A beam tree is a collection of 3-D wedges (beams), bounded by
 planes, projecting out from some center point, in this case the
 viewpoint, as shown in Figure 64.5.
 
-In John’s design, the beam tree started out consisting of a single beam
+In John's design, the beam tree started out consisting of a single beam
 describing the frustum; everything outside that beam was marked solid
 (so nothing would draw there), and the inside of the beam was marked
 empty. As each new polygon was reached while walking the world BSP tree
@@ -45,16 +45,16 @@ aforementioned bulk culling to the frustum.
 
 The early-out feature of the beam tree—stopping when the beam tree
 becomes solid—seems appealing, because it appears to cap worst-case
-performance. Unfortunately, there are still scenes where it’s possible
+performance. Unfortunately, there are still scenes where it's possible
 to see all the way to the sky or the back wall of the world, so in the
 worst case, all polygons in the frustum will still have to be tested
 against the beam tree. Similar problems can arise from tiny cracks due
 to numeric precision limitations. Beam-tree clipping is fairly
 time-consuming, and in scenes with long view distances, such as views
 across the top of a level, the total cost of beam processing slowed
-Quake’s frame rate to a crawl. So, in the end, the beam-tree approach
-proved to suffer from much the same malady as the painter’s algorithm:
-The worst case was much worse than the average case, and it didn’t scale
+Quake's frame rate to a crawl. So, in the end, the beam-tree approach
+proved to suffer from much the same malady as the painter's algorithm:
+The worst case was much worse than the average case, and it didn't scale
 well with increasing level complexity.
 
 ### 3-D Engine du Jour {#Heading9}
@@ -62,8 +62,8 @@ well with increasing level complexity.
 Once the beam tree was working, John relentlessly worked at speeding up
 the 3-D engine, always trying to improve the design, rather than
 tweaking the implementation. At least once a week, and often every day,
-he would walk into my office and say “Last night I couldn’t get to
-sleep, so I was thinking...” and I’d know that I was about to get my
+he would walk into my office and say "Last night I couldn't get to
+sleep, so I was thinking..." and I'd know that I was about to get my
 mind stretched yet again. John tried many ways to improve the beam tree,
 with some success, but more interesting was the profusion of wildly
 different approaches that he generated, some of which were merely
@@ -79,12 +79,12 @@ sparked.
 Rays are cast in an 8x8 screen-pixel grid; this is a highly efficient
 operation because the first intersection with a surface can be found by
 simply clipping the ray into the BSP tree, starting at the viewpoint,
-until a solid leaf is reached. If adjacent rays don’t hit the same
+until a solid leaf is reached. If adjacent rays don't hit the same
 surface, then a ray is cast halfway between, and so on until all
 adjacent rays either hit the same surface or are on adjacent pixels;
 then the block around each ray is drawn from the polygon that was hit.
 This scales very well, being limited by the number of pixels, with no
-overdraw. The problem is dropouts; it’s quite possible for small
+overdraw. The problem is dropouts; it's quite possible for small
 polygons to fall between rays and vanish.
 
 #### Vertex-Free Surfaces {#Heading11}
@@ -92,7 +92,7 @@ polygons to fall between rays and vanish.
 The world is represented by a set of surface planes. The polygons are
 implicit in the plane intersections, and are extracted from the planes
 as a final step before drawing. This makes for fast clipping and a very
-small data set (planes are far more compact than polygons), but it’s
+small data set (planes are far more compact than polygons), but it's
 time-consuming to extract polygons from planes.
 
 #### The Draw-Buffer {#Heading12}
@@ -112,14 +112,14 @@ parallel while 8 pixels are processed.
 Polygons are rasterized into spans, which are added to a global span
 list and clipped against that list so that only the nearest span at each
 pixel remains. Little sorting is needed with front-to-back walking,
-because if there’s any overlap, the span already in the list is nearer.
+because if there's any overlap, the span already in the list is nearer.
 This eliminates overdraw, but at the cost of a lot of span arithmetic;
 also, every polygon still has to be turned into spans.
 
 #### Portals {#Heading14}
 
 The holes where polygons are missing on surfaces are tracked, because
-it’s only through such portals that line-of-sight can extend. Drawing
+it's only through such portals that line-of-sight can extend. Drawing
 goes front-to-back, and when a portal is encountered, polygons and
 portals behind it are clipped to its limits, until no polygons or
 portals remain visible. Applied recursively, this allows drawing only
@@ -138,7 +138,7 @@ whereby a single, linear walk of a DOOM BSP tree produces zero-overdraw
 complex problem, though, and by the end of the week John was frustrated
 by the increasing complexity and persistent glitches in the visibility
 code. Although the direct-BSP approach was getting closer to working, it
-was taking more and more tweaking, and a simple, clean design didn’t
+was taking more and more tweaking, and a simple, clean design didn't
 seem to be falling out. When I left work one Friday, John was preparing
 to try to get the direct-BSP approach working properly over the weekend.