Normal quotes

69-04.md

@@ -4,15 +4,15 @@
 
 Once the vertices are drawn, the triangles are processed one at a time.
 Each triangle that makes it through backface culling is then drawn with
-recursive subdivision. If any of the triangle’s sides is more than one
+recursive subdivision. If any of the triangle's sides is more than one
 pixel long in either x or y—that is, if the triangle contains any pixels
-that aren’t at vertices—then that side is split in half as nearly as
+that aren't at vertices—then that side is split in half as nearly as
 possible at given integer coordinates, and a new vertex is created at
 the split, with texture and screen coordinates that are halfway between
 those of the vertices at the endpoints. (The same splitting could be
 done for lighting, but we found that for small triangles—the sort that
 subdivision works well on—it was adequate to flat-shade each triangle at
-the light level of the first vertex, so we didn’t bother with Gouraud
+the light level of the first vertex, so we didn't bother with Gouraud
 shading.) The halfway values can be calculated very quickly with shifts.
 This vertex is drawn, and then each of the two resulting triangles is
 then processed recursively in the same way, as shown in Figure 69.2.
@@ -26,7 +26,7 @@ very simple and easily optimized, especially by comparison with a
 generalized triangle rasterizer.
 
 Subdivision rasterization introduces considerably more error than affine
-texture mapping, and doesn’t draw exactly the right triangle shape, but
+texture mapping, and doesn't draw exactly the right triangle shape, but
 the difference is very hard to detect for triangles that contain only a
 few pixels. We found that the point at which the difference between the
 two rasterizers becomes noticeable was surprisingly close: 30 or 40 feet
@@ -48,7 +48,7 @@ clear success.
 
 **LISTING 69.1 L69-1.C**
 
-    // Quake’s recursive subdivision triangle rasterizer; draws all
+    // Quake's recursive subdivision triangle rasterizer; draws all
     // pixels in a triangle other than the vertices by splitting an
     // edge to form a new vertex, drawing the vertex, and recursively
     // processing each of the two new triangles formed by using the
@@ -69,7 +69,7 @@ clear success.
     int    z;
     short  *zbuf;
 
-    // try to find an edge that’s more than one pixel long in x or y
+    // try to find an edge that's more than one pixel long in x or y
     d = lp2[0] - lp1[0];
     if (d < -1 || d > 1)
     goto split;
@@ -129,20 +129,20 @@ clear success.
 
     z = new[5]>>16;
 
-    // point to the pixel’s z-buffer entry, looking up the scanline start
+    // point to the pixel's z-buffer entry, looking up the scanline start
     // address based on screen y and adding in the screen x coordinate
     zbuf = zspantable[new[1]] + new[0];
 
-    // draw the split vertex if it’s not obscured by something nearer, as
+    // draw the split vertex if it's not obscured by something nearer, as
     // indicated by the z-buffer
     if (z >= *zbuf)
     {
     int     pix;
 
-    // set the z-buffer to the new pixel’s distance
+    // set the z-buffer to the new pixel's distance
     *zbuf = z;
 
-    // get the texel from the model’s skin bitmap, according to
+    // get the texel from the model's skin bitmap, according to
     // the s and t texture coordinates, and translate it through
     // the lighting look-up table set according to the first
     // vertex for the original (top-level) triangle.  Both s and
@@ -167,27 +167,27 @@ clear success.
 #### More Ideas that Might Work {#Heading11}
 
 Useful as subdivision rasterization proved to be, we by no means think
-that we’ve maxed out triangle-model drawing, if only because we spent
+that we've maxed out triangle-model drawing, if only because we spent
 far less design and development time on subdivision than on the affine
-rasterizer, so it’s likely that there’s quite a bit more performance to
+rasterizer, so it's likely that there's quite a bit more performance to
 be found for drawing small triangles. For example, it could be faster to
 precalculate drawing masks or even precompile drawing code for all
 possible small triangles (say, up to 4x4 or 5x5), and the memory
-footprint looks reasonable. (It’s worth noting that both precalculated
+footprint looks reasonable. (It's worth noting that both precalculated
 drawing and subdivision rasterization are only possible because we snap
 to integer coordinates; none of this stuff works with fixed-point
 vertices.)
 
 More interesting still is the stack-based rendering described in the
-article “Time/Space Tradeoffs for Polygon Mesh Rendering,” by Bar-Yehuda
+article "Time/Space Tradeoffs for Polygon Mesh Rendering," by Bar-Yehuda
 and Gotsman, in the April, 1996 *ACM Transactions on Graphics*.
 Unfortunately, the article is highly abstract and slow going, but the
-bottom line is that it’s possible to represent a triangle mesh as a
+bottom line is that it's possible to represent a triangle mesh as a
 stream of commands that place vertices in a stack, remove them from the
 stack, and draw triangles using the vertices in the stack. This results
 in excellent CPU cache coherency, because rather than indirecting all
 over a vertex pool to retrieve vertex data, all vertices reside in a
-tiny stack that’s guaranteed to be in the cache. Local variables used
+tiny stack that's guaranteed to be in the cache. Local variables used
 while drawing can be stored in a small block next to the stack, and the
 stream of commands representing the model is accessed sequentially from
 start to finish, so cache utilization should be very high. As processors
@@ -196,10 +196,10 @@ optimizations of this sort will become steadily more important in
 improving drawing performance.
 
 As with so many aspects of 3-D, there is no one best approach to drawing
-triangle models, and no such thing as the fastest code. In a way, that’s
-frustrating, but the truth is, it’s these nearly infinite possibilities
+triangle models, and no such thing as the fastest code. In a way, that's
+frustrating, but the truth is, it's these nearly infinite possibilities
 that make 3-D so interesting; not only is it an endless, varied
-challenge, but there’s almost always a better solution waiting to be
+challenge, but there's almost always a better solution waiting to be
 found.
 
   ------------------------ --------------------------------- --------------------