Normal quotes

62-04.md

@@ -6,7 +6,7 @@
 
 Now that we have all the walls clipped to the frustum, with vertices
 projected into screen coordinates, all we have to do is draw them back
-to front; that’s the job of **DrawWallsBackToFront()**. Basically, this
+to front; that's the job of **DrawWallsBackToFront()**. Basically, this
 routine walks the BSP tree, descending recursively from each node to
 draw the farther children of each node first, then the wall at the node,
 then the nearer children. In the interests of efficiency, this
@@ -22,14 +22,14 @@ toward the viewer, it is drawn as a solid polygon. The polygon filler
 (not shown in Listing 62.1) is a modification of the polygon filler I
 presented in Chapters 38 and 39.
 
-It’s worth noting how backface culling and front/back wall orientation
+It's worth noting how backface culling and front/back wall orientation
 testing are performed. (Note that walls are always one-sided, visible
 only from the front.) I discussed backface culling in general in the
 previous chapter, and mentioned two possible approaches: generating a
 screenspace normal (perpendicular vector) to the polygon and seeing
 which way that points, or taking the world or screenspace dot product
 between the vector from the viewpoint to any polygon point and the
-polygon’s normal and checking the sign. Listing 62.1 does both, but
+polygon's normal and checking the sign. Listing 62.1 does both, but
 because our BSP tree is 2-D and the viewer is always upright, we can
 save some work.
 
@@ -39,17 +39,17 @@ end vertex. There are only two possible ways that a wall can be
 positioned in screenspace, then: viewed from the front, in which case
 the start vertex is to the left of the end vertex, or viewed from the
 back, in which case the start vertex is to the right of the end vertex,
-as shown in Figure 62.4. So we can tell which side of a wall we’re
+as shown in Figure 62.4. So we can tell which side of a wall we're
 seeing, and thus backface cull, simply by comparing the screenspace x
 coordinates of the start and end vertices, a simple 2-D version of
 checking the direction of the screenspace normal.
 
 The wall orinetation test used for walking the BSP tree, performed in
 **WallFacingViewer()** takes the other approach, and checks the
-viewspace sign of the dot product of the wall’s normal with a vector
+viewspace sign of the dot product of the wall's normal with a vector
 from the viewpoint to the wall. Again, this code takes advantage of the
 2-D nature of the tree to generate the wall normal by swapping x and z
-and altering signs. We can’t use the quicker screenspace x test here
+and altering signs. We can't use the quicker screenspace x test here
 that we used for backface culling, because not all walls can be
 projected into screenspace; for example, trying to project a wall at
 z==0 would result in division by zero.
@@ -68,7 +68,7 @@ a tiny BSP rendering demo, because 3D rendering, even when based on a
 2-D BSP tree, requires a substantial amount of code and complexity.
 Listing 62.1 is reasonably close to a minimum rendering engine, and is
 specifically intended to illuminate basic BSP principles, given the
-space limitations of one chapter in a book that’s already larger than it
+space limitations of one chapter in a book that's already larger than it
 should be. Think of Listing 62.1 as a learning tool and a starting
 point.
 
@@ -78,9 +78,9 @@ necessary to go to 3-D BSP trees to get a normal-looking world?
 
 No. Although 3-D BSP trees offer many advantages in that they allow
 arbitrary datasets with viewing in any arbitrary direction and, in
-truth, aren’t much more complicated than 2-D BSP trees for back-to-front
+truth, aren't much more complicated than 2-D BSP trees for back-to-front
 drawing, they do tend to be larger and more difficult to debug, and they
-aren’t necessary for floors and ceilings. One way to get floors and
+aren't necessary for floors and ceilings. One way to get floors and
 ceilings out of a 2-D BSP tree is to change the nature of the BSP tree
 so that polygons are no longer stored in the splitting nodes. Instead,
 each leaf of the tree—that is, each subspace carved out by the