Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

20
57-02.md
View file

@ -6,20 +6,20 @@
The double-DDA texture-mapping code presented in the previous chapter
worked adequately, but there were two things about it that left me less
than satisfied. One flaw was performance; I’ll address that shortly. The
than satisfied. One flaw was performance; I'll address that shortly. The
other flaw was the way textures shifted noticeably as the orientations
of the polygons onto which they were mapped changed.
The previous chapter’s code followed the standard polygon inside/outside
The previous chapter's code followed the standard polygon inside/outside
rule for determining which pixels in the source texture map were to be
mapped: Pixels that mapped exactly to the left and top destination edges
were considered to be inside, and pixels that mapped exactly to the
right and bottom destination edges were considered to be outside. That’s
right and bottom destination edges were considered to be outside. That's
fine for filling polygons, but when copying texture maps, it causes
different edges of the texture map to be omitted, depending on the
destination orientation, because different edges of the texture map
correspond to the right and bottom destination edges, depending on the
current rotation. Also, the previous chapter’s code truncated to get
current rotation. Also, the previous chapter's code truncated to get
integer source coordinates. This, together with the orientation problem,
meant that when a texture turned upside down, it slowed one new row and
one new column of pixels from the next row and column of the texture
@ -33,7 +33,7 @@ math.*
Listing 57.1 is one solution to these problems. This code, which
replaces the equivalently named function presented in the previous
chapter (and, of course, is present in the X-Sharp archive in this
chapter’s subdirectory of the listings disk), makes no attempt to follow
chapter's subdirectory of the listings disk), makes no attempt to follow
the standard polygon inside/outside rules when mapping the source.
Instead, it advances a half-step into the texture map before drawing the
first pixel, so pixels along all edges are half included. Rounding
@ -84,9 +84,9 @@ level of orientation-dependent asymmetry.
SourceStepY = FixedDiv(RightEdge->SourceY - SourceY, DestWidth);
/* Advance 1/2 step in the stepping direction, to space scanned pixels
evenly between the left and right edges. (There’s a slight inaccuracy
evenly between the left and right edges. (There's a slight inaccuracy
in dividing negative numbers by 2 by shifting rather than dividing,
but the inaccuracy is in the least significant bit, and we’ll just
but the inaccuracy is in the least significant bit, and we'll just
live with it.) */
SourceX += SourceStepX >> 1;
SourceY += SourceStepY >> 1;
@ -132,10 +132,10 @@ the rest.
#### Fast Texture Mapping {#Heading7 align="center"}
Of course, there’s a problem with mapping a texture across many
Of course, there's a problem with mapping a texture across many
polygons: Texture mapping is slow. If you run DEMO1 and move the ball up
close to the screen, you’ll see that the ball slows considerably
whenever a texture swings around into view. To some extent that can’t be
close to the screen, you'll see that the ball slows considerably
whenever a texture swings around into view. To some extent that can't be
helped, because each pixel of a texture-mapped polygon has to be
calculated and drawn independently. Nonetheless, we can certainly
improve the performance of texture mapping a good deal over what I