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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

8
51-06.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=51//-->
<!--PAGES=965-967//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -123,9 +123,9 @@ extern int DisplayedPage, NonDisplayedPage;
extern struct Rect EraseRect[];
</PRE>
<!-- END CODE //-->
<H3><A NAME="Heading6"></A><FONT COLOR="#000077">A Note on Rounding Negative Numbers</FONT></H3>
<H3><A NAME="Heading6"></A>A Note on Rounding Negative Numbers</H3>
<P>In the previous chapter, I added 0.5 and truncated in order to round values from floating-point to integer format. Here, in Listing 51.2, I&rsquo;ve switched to adding 0.5 and using the <B>floor()</B> function. For positive values, the two approaches are equivalent; for negative values, only the <B>floor()</B> approach works properly.</P>
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Object Representation</FONT></H3>
<H3><A NAME="Heading7"></A>Object Representation</H3>
<P>Each object consists of a list of vertices and a list of faces, with the vertices of each face defined by pointers into the vertex list; this allows each vertex to be transformed exactly once, even though several faces may share a single vertex. Each object contains the vertices not only in their original, untransformed state, but in three other forms as well: transformed to view space, transformed and projected to screen space, and converted to screen coordinates. Earlier, we saw that it can be convenient to store the screen coordinates within the object, so that if the object hasn&rsquo;t moved with respect to the viewer, it can be redrawn without the need for recalculation, but why bother storing the view and screen space forms of the vertices as well?
</P>
<P>The screen space vertices are useful for some sorts of hidden surface removal. For example, to determine whether two polygons overlap as seen by the viewer, you must first know how they look to the viewer, accounting for perspective; screen space provides that information. (So do the final screen coordinates, but with less accuracy, and without any Z information.) The view space vertices are useful for collision and proximity detection; screen space can&rsquo;t be used here, because objects are distorted by the perspective projection into screen space. World space would serve as well as view space for collision detection, but because it&rsquo;s possible to transform directly from object space to view space with a single matrix, it&rsquo;s often preferable to skip over world space. It&rsquo;s not mandatory that vertices be stored for all these different spaces, but the coordinates in all those spaces have to be calculated as intermediate steps anyway, so we might as well keep them around for those occasions when they&rsquo;re needed.</P><P><BR></P>
@ -141,7 +141,7 @@ extern struct Rect EraseRect[];
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->