Change bold code snippets to inline code blocks

67-05.md

@@ -42,11 +42,11 @@ would be dynamically allocated from a vertex pool, so each polygon
 wouldn't have to contain enough space for the maximum possible number of
 vertices.
 
-Each surface has a field named **state**, which is incremented when a
+Each surface has a field named `state`, which is incremented when a
 leading edge for that surface is encountered, and decremented when a
 trailing edge is reached. A surface is activated by a leading edge only
-if **state** increments to 1, and is deactivated by a trailing edge only
-if **state** decrements to 0. This is another guard against arithmetic
+if `state` increments to 1, and is deactivated by a trailing edge only
+if `state` decrements to 0. This is another guard against arithmetic
 problems, in this case quantization during the conversion of vertex
 coordinates from floating point to fixed point. Due to this conversion,
 it is possible, although rare, for a polygon that is viewed nearly
@@ -62,7 +62,7 @@ Lastly, as discussed in Chapter 66, Listing 67.1 uses the gradients for
 active surfaces each time a leading edge needs to be sorted into the
 surface stack. The natural origin for gradient calculations is the
 center of the screen, which is (x,y) coordinate (0,0) in viewspace.
-However, when the gradients are calculated in **AddPolygonEdges()**, the
+However, when the gradients are calculated in `AddPolygonEdges()`, the
 origin value is calculated at the upper-left corner of the screen. This
 is done so that screen x and y coordinates can be used directly to
 calculate 1/z, with no need to adjust the coordinates to be relative to