Change bold code snippets to inline code blocks

This commit is contained in:
James Gregory 2013-12-31 17:12:29 +11:00
commit 3c76d884ef
185 changed files with 1772 additions and 1772 deletions

View file

@ -14,7 +14,7 @@ pages: 1157-1160
Conceptually rendering from a BSP tree really is that simple, but the
implementation is a bit more complicated. The full rendering pipeline,
as coordinated by **UpdateWorld()**, is this:
as coordinated by `UpdateWorld()`, is this:
* Update the current location.
* Transform all wall endpoints into viewspace (the world as seen from
@ -37,7 +37,7 @@ The sample BSP program performs first-person rendering; that is, it
renders the world as seen from your eyes as you move about. The rate of
movement is controlled by key-handling code that's not shown in Listing
62.1; however, the variables set by the key-handling code are used in
**UpdateViewPos()** to bring the current location up to date.
`UpdateViewPos()` to bring the current location up to date.
Note that the view position can change not only in x and z (movement
around the but only viewing horizontally. Although the BSP tree is only
@ -54,7 +54,7 @@ The viewing angle (which controls direction of movement as well as view
direction) can sweep through the full 360 degrees around the viewpoint,
so long as it remains horizontal. The viewing angle is controlled by the
key handler, and is used to define a unit vector stored in
**currentorientation** that explicitly defines the view direction (the z
`currentorientation` that explicitly defines the view direction (the z
axis of viewspace), and implicitly defines the x axis of viewspace,
because that axis is at right angles to the z axis, where x increases to
the right of the viewer.
@ -62,7 +62,7 @@ the right of the viewer.
As I discussed in the previous chapter, rotation to a new coordinate
system can be performed by using the dot product to project points onto
the axes of the new coordinate system, and that's what
**TransformVertices()** does, after first translating (moving) the
`TransformVertices()` does, after first translating (moving) the
coordinate system to have its origin at the viewpoint. (It's necessary
to perform the translation first so that the viewing rotation is around
the viewpoint.) Note that this operation can equivalently be viewed as a
@ -70,7 +70,7 @@ matrix math operation, and that this is in fact the more common way to
handle transformations.
At the same time, the points are scaled in x according to
**PROJECTION\_RATIO** to provide the desired field of view. Larger scale
`PROJECTION_RATIO` to provide the desired field of view. Larger scale
values result in narrower fields of view.
When this is done the walls are in viewspace, ready to be clipped.
@ -85,7 +85,7 @@ walls—walls that lie entirely in the frustum—should be drawn in their
entirety, fully clipped walls should not be drawn, and partially clipped
walls must be trimmed before being drawn.
In Listing 62.1, **ClipWalls()** does this in three steps for each wall
In Listing 62.1, `ClipWalls()` does this in three steps for each wall
in turn. First, the z coordinates of the two ends of the wall are
calculated. (Remember, walls are vertical and their ends go straight up
and down, so the top and bottom of each end have the same x and z
@ -116,7 +116,7 @@ and -x==z.
The final clip stage is clipping by y coordinate, and this is the most
complicated, because vertical walls can be clipped at an angle in y, as
shown in Figure 62.3, so true 3-D clipping of all four wall vertices is
involved. We handle this in **ClipWalls()** by detecting trivial
involved. We handle this in `ClipWalls()` by detecting trivial
rejection in y, using y==z and ==z as the y boundaries of the frustum.
However, we leave partial clipping to be handled as a 2-D clipping
problem; we are able to do this only because our earlier z-clip to the
@ -131,6 +131,6 @@ partially visible. All we have to do is project these vertices according
to z distance—that is, perform perspective projection—and scale the
results to the width of the screen, then we'll be ready to draw.
Although this step is logically separate from clipping, it is performed
as the last step for visible walls in **ClipWalls()**.
as the last step for visible walls in `ClipWalls()`.
![**Figure 62.3**  *Why y clipping is more complex than x or z clipping.*](images/62-03.jpg)