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

6
38-04.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=38//-->
<!--PAGES=720-721//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -49,7 +49,7 @@
<P>Once we know where the left edge starts in the vertex list, we can scan-convert it a line segment at a time until the bottom vertex is reached. Each point is stored as the starting X coordinate for the corresponding scan line in the list we&rsquo;ll pass to <B>DrawHorizontalLineList</B>. The nearest X coordinate on each scan line that&rsquo;s on or to the right of the left edge is selected. The last point of each line segment making up the left edge isn&rsquo;t scan-converted, producing two desirable effects. First, it avoids drawing each vertex twice; two lines come into every vertex, but we want to scan-convert each vertex only once. Second, not scan-converting the last point of each line causes the bottom scan line of the polygon not to be drawn, as required by our rules. The first scan line of the polygon is also skipped if the top isn&rsquo;t flat.</P>
<P>Now we need to scan-convert the right edge into the ending X coordinate fields of the line list. This is performed in the same manner as for the left edge, except that every line in the right edge is moved one pixel to the left before being scan-converted. Why? We want the nearest point to the left of but not on the right edge, so that the right edge itself isn&rsquo;t drawn. As it happens, drawing the nearest point on or to the right of a line moved one pixel to the left is exactly the same as drawing the nearest point to the left of but not on that line in its original location. Sketch it out and you&rsquo;ll see what I mean. <P>Once the two edges are scan-converted, the whole line list is passed to <B>DrawHorizontalLineList</B>, and the polygon is drawn.</P>
<P>Finis.</P>
<H3><A NAME="Heading7"></A><FONT COLOR="#000077">Oddball Cases</FONT></H3>
<H3><A NAME="Heading7"></A>Oddball Cases</H3>
<P>Listing 38.1 handles zero-length segments (multiple vertices at the same location) by ignoring them, which will be useful down the road because scaled-down polygons can end up with nearby vertices moved to the same location. Horizontal line segments are fine anywhere in a polygon, too. Basically, Listing 38.1 scan-converts between active edges (the edges that define the extent of the polygon on each scan line) and both horizontal and zero-length lines are non-active; neither advances to another scan line, so they don&rsquo;t affect the edges being scanned.
</P>
<P>I&rsquo;ve limited this chapter&rsquo;s code to merely demonstrating the principles of filling convex polygons, and the listings given are by no means fast. In the next chapter, we&rsquo;ll spice things up by eliminating the floating point calculations and pixel-at-a-time drawing and tossing a little assembly language into the mix.</P><P><BR></P>
@ -65,7 +65,7 @@
<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 -->