Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
James Gregory
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
14
70-06.html
14
70-06.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=70//-->
|
||||
<!--PAGES=1286-1288//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -36,19 +36,19 @@
|
|||
</TABLE>
|
||||
</CENTER>
|
||||
<P><BR></P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading12"></A><FONT COLOR="#000077">The Subdivision Rasterizer</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading12"></A>The Subdivision Rasterizer</H4>
|
||||
<P>This rasterizer, which we call the <I>subdivision rasterizer</I>, first draws all the vertices in the model. Then it takes each front-facing triangle, and determines if it has a side that’s at least two pixels long. If it does, we split that side into two pieces at the pixel nearest to the middle (using adds and shifts to average the endpoints of that side), draw the vertex at the split point, and process each of the two split triangles recursively, until we get down to triangles that have only one-pixel sides and hence have nothing left to draw. This approach is hideously slow and quite ugly (due to inaccuracies from integer quantization) for 100-pixel triangles—but it’s very fast for, say, five-pixel triangles, and is indistinguishable from more accurate rasterization when a model is 25 or 50 feet away. Better yet, the subdivider is ridiculously simple—a few dozen lines of code, far simpler than the affine rasterizer—and was implemented in an evening, immediately making the drawing of distant models about three times as fast, a very good return for a bit of conceptual work. The affine rasterizer got fairly close to the same performance with further optimization—in the range of 10% to 50% slower—but that took weeks of difficult programming.</P>
|
||||
<P>We switch between the two rasterizers based on the model’s distance and average triangle size, and in almost any scene, most models are far enough away so subdivision rasterization is used. There are undoubtedly faster ways yet to rasterize distant models adequately well, but the subdivider was clearly a win, and is a good example of how thinking in a radically different direction can pay off handsomely.</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading13"></A><FONT COLOR="#000077">Sprites</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading13"></A>Sprites</H4>
|
||||
<P>We had hoped to be able to eliminate sprites completely, making Quake 100% 3-D, but sprites—although sometimes very visibly 2-D—were used for a few purposes, most noticeably the cores of explosions. As of CGDC last year, explosions consisted of an exploding spray of particles (discussed below), but there just wasn’t enough visual punch with that representation; adding a series of sprites animating an explosion did the trick. (In hindsight, we probably should have made the explosions polygon models rather than sprites; it would have looked about as good, and the few sprites we used didn’t justify the considerable amount of code and programming time required to support them.) Drawing a sprite is similar to drawing a normal polygon, complete with perspective correction, although of course the inner loop must detect and skip over transparent pixels, and must also perform z-buffering.
|
||||
</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading14"></A><FONT COLOR="#000077">Particles</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading14"></A>Particles</H4>
|
||||
<P>The last drawing entity type is particles. Each particle is a solid-colored rectangle, scaled by distance from the viewer and drawn with z-buffering. There can be up to 2,000 particles in a scene, and they are used for rocket trails, explosions, and the like. In one sense, particles are very primitive technology, but they allow effects that would be extremely difficult to do well with the other types of entities, and they work well in tandem with other entities, as, for example, providing a trail of fire behind a polygon-model lava ball that flies into the air, or generating an expanding cloud around a sprite explosion core.
|
||||
</P>
|
||||
<H3><A NAME="Heading15"></A><FONT COLOR="#000077">How We Spent Our Summer Vacation: After Shipping Quake</FONT></H3>
|
||||
<H3><A NAME="Heading15"></A>How We Spent Our Summer Vacation: After Shipping Quake</H3>
|
||||
<P>Since shipping Quake in the summer of 1996, we’ve extended it in several ways: We’ve worked with Rendition to port it to the Verite accelerator chip, we’ve ported it to OpenGL, we’ve ported it to Win32, we’ve done QuakeWorld, and we’ve added features for Quake 2. I’ll discuss each of these briefly.
|
||||
</P>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading16"></A><FONT COLOR="#000077">Verite Quake</FONT></H4>
|
||||
<H4 ALIGN="LEFT"><A NAME="Heading16"></A>Verite Quake</H4>
|
||||
<P>Verite Quake (VQuake) was the first hardware-accelerated version of Quake. It looks extremely good, due to bilinear texture filtering, which eliminates most pixel aliasing, and because it provides good performance at higher resolutions such as 512x384 and 640x480. Implementing VQuake proved to be an interesting task, for two reasons: The Verite chip’s fill rate was marginal for Quake’s needs, and Verite contains a programmable RISC chip, enabling more sophisticated processing than most 3-D accelerators. The need to squeeze as much performance as possible out of Verite ruled out the use of a standard API such as Direct 3D or OpenGL; instead, VQuake uses Rendition’s proprietary API, Speedy3D, with the addition of some special calls and custom Verite code.
|
||||
</P>
|
||||
<P>Interestingly, VQuake is very similar to software Quake; in order to allow Verite to handle the high pixel processing loads of high-res, VQuake uses an edge list and builds span lists on the CPU, just as in software Quake, then Verite DMAs the span descriptors to onboard memory and draws them. (This was only possible because Verite is fully programmable; most accelerators wouldn’t be able to support this architecture.) Similarly, the CPU builds lit, tiled surfaces in system RAM, then Verite DMAs them to an onboard surface cache, from which they are texture-mapped. In short, VQuake is very much like normal Quake, except that the drawing of the spans is done by a specialized processor.</P>
|
||||
|
|
@ -66,7 +66,7 @@
|
|||
|
||||
<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