Change bold code snippets to inline code blocks

67-04.md

@@ -19,19 +19,19 @@ needed was backface culling and a polygon rasterizer.
 Listing 67.1 replaces this simple pipeline with a three-stage HSR
 process. After backface culling, the edges of each of the polygons in
 the scene are added to the global edge list, by way of
-**AddPolygonEdges()**. After all edges have been added, the edges are
-turned into spans by **ScanEdges()**, with each pixel on the screen
+`AddPolygonEdges()`. After all edges have been added, the edges are
+turned into spans by `ScanEdges()`, with each pixel on the screen
 being covered by one and only one span (that is, there's no overdraw).
 Once all the spans have been generated, they're drawn by
-**DrawSpans()**, and rasterization is complete.
+`DrawSpans()`, and rasterization is complete.
 
-There's nothing tricky about **AddPolygonEdges()**, and **DrawSpans()**,
+There's nothing tricky about `AddPolygonEdges()`, and `DrawSpans()`,
 as implemented in Listing 67.1, is very straightforward as well. In an
 implementation that supported texture mapping, however, all the spans
 wouldn't be put on one global span list and drawn at once, as is done in
 Listing 67.1, because that would result in drawing spans from all the
 surfaces in no particular order. (A surface is a drawing object that's
-originally described by a polygon, but in **ScanEdges()** there is no
+originally described by a polygon, but in `ScanEdges()` there is no
 polygon in the classic sense of a set of vertices bounding an area, but
 rather just a set of edges and a surface that describes how to draw the
 spans outlined by those edges.) That would mean constantly skipping from
@@ -43,13 +43,13 @@ surface, and draw all the spans for one surface before moving on to the
 next surface.
 
 The core of Listing 67.1, and the most complex aspect of 1/z-sorted
-spans, is **ScanEdges()**, where the global edge list is converted into
+spans, is `ScanEdges()`, where the global edge list is converted into
 a set of spans describing the nearest surface at each pixel. This
 process is actually pretty simple, though, if you think of it as
 follows:
 
 For each scan line, there is a set of active edges, which are those
-edges that intersect the scan line. A good part of **ScanEdges()** is
+edges that intersect the scan line. A good part of `ScanEdges()` is
 dedicated to adding any edges that first appear on the current scan line
 (scan lines are processed from the top scan line on the screen to the
 bottom), removing edges that reach their bottom on the current scan
@@ -58,7 +58,7 @@ next scan can be processed from left to right. All this is per-scan-line
 maintenance, and is basically just linked list insertion, deletion, and
 sorting.
 
-The heart of the action is the loop in **ScanEdges()** that processes
+The heart of the action is the loop in `ScanEdges()` that processes
 the edges on the current scan line from left to right, generating spans
 as needed. The best way to think of this loop is as a surface event
 processor, where each edge is an event with an associated surface. Each
@@ -74,7 +74,7 @@ leading and trailing edges do not need to be explicitly paired, because
 they are implicitly paired by pointing to the same surface. This saves
 the memory and time that would otherwise be needed to track edge pairs.
 
-One more element is required in order for **ScanEdges()** to work
+One more element is required in order for `ScanEdges()` to work
 efficiently. Each time a leading or trailing edge occurs, it must be
 determined whether its surface is nearest (at a larger 1/z value than
 any currently active surface). In addition, for leading edges, the