Change bold code snippets to inline code blocks
This commit is contained in:
parent
f658bfbb40
commit
3c76d884ef
185 changed files with 1772 additions and 1772 deletions
16
62-03.md
16
62-03.md
|
|
@ -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()`.
|
||||
|
||||

|
||||
|
|
|
|||
Loading…
Reference in a new issue