Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
12
57-02.html
12
57-02.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=57//-->
|
||||
<!--PAGES=1065-1068//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,12 +36,12 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A><FONT COLOR="#000077">Texture Mapping: Orientation Independence</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading5"></A>Texture Mapping: Orientation Independence</H4>
|
||||
<P>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 other flaw was the way textures shifted noticeably as the orientations of the polygons onto which they were mapped changed.
|
||||
</P>
|
||||
<P>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 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 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 map. This asymmetry was quite visible, and not at all the desired effect.</P>
|
||||
<P><A NAME="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/57-01.jpg',408,249 )"> --><IMG SRC="images/57-01.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/57-01.jpg',408,249)"> --><FONT COLOR="#000077"><B>Figure 57.1</B></FONT></A> <I>Gaps caused by mixing fixed-point and all-integer math.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/57-01.jpg',408,249)"> --><B>Figure 57.1</B></A> <I>Gaps caused by mixing fixed-point and all-integer math.</I>
|
||||
</P>
|
||||
<P>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 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 rather than truncation to texture-map coordinates is also performed. The result is that the texture map stays pretty much centered within the destination polygon as the destination rotates, with a much-reduced level of orientation-dependent asymmetry.
|
||||
</P>
|
||||
|
|
@ -120,10 +120,10 @@ void ScanOutLine(EdgeScan * LeftEdge, EdgeScan * RightEdge)
|
|||
}
|
||||
</PRE>
|
||||
<!-- END CODE //-->
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading6"></A><FONT COLOR="#000077">Mapping Textures across Multiple Polygons</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading6"></A>Mapping Textures across Multiple Polygons</H4>
|
||||
<P>One of the truly nifty things about double-DDA texture mapping is that it is not limited to mapping a texture onto a single polygon. A single texture can be mapped across any number of adjacent polygons simply by having polygons that share vertices in 3-space also share vertices in the texture map. In fact, the demonstration program DEMO1 in the X-Sharp archive maps a single texture across two polygons; this is the blue-on-green pattern that stretches across two panels of the spinning ball. This capability makes it easy to produce polygon-based objects with complex surfaces (such as banding and insignia on spaceships, or even human figures). Just map the desired texture onto the underlying polygonal framework of an object, and let double-DDA texture mapping do the rest.
|
||||
</P>
|
||||
<H4 ALIGN="CENTER"><A NAME="Heading7"></A><FONT COLOR="#000077">Fast Texture Mapping</FONT></H4>
|
||||
<H4 ALIGN="CENTER"><A NAME="Heading7"></A>Fast Texture Mapping</H4>
|
||||
<P>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 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 presented in the previous chapter.
|
||||
</P>
|
||||
<P>By and large, there are two keys to improving PC graphics performance. The first—no surprise—is assembly language. The second, without which assembly language is far less effective, is understanding exactly where the cycles go in inner loops. In our case, that means understanding where the bottlenecks are in Listing 57.1.</P>
|
||||
|
|
@ -140,7 +140,7 @@ void ScanOutLine(EdgeScan * LeftEdge, EdgeScan * RightEdge)
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue