Retidy, removing align=left from headings and empty paragraphs

This commit is contained in:
James Gregory 2013-12-30 15:37:13 +11:00
commit a96a114403
362 changed files with 8472 additions and 5040 deletions

View file

@ -1,5 +1,4 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
@ -19,17 +18,21 @@
<center>
<table border="1">
<tr>
<td><a href="66-03.html">Previous</a></td>
<td>
<a href="66-03.html">Previous</a>
</td>
<td><a href="index.html">Table of Contents</a></td>
<td>
<a href="index.html">Table of Contents</a>
</td>
<td><a href="67-01.html">Next</a></td>
<td>
<a href="67-01.html">Next</a>
</td>
</tr>
</table>
</center>
<p><br /></p>
<p>The obvious way to get a 1/z value at any arbitrary point on a polygon is to calculate 1/z at the vertices, interpolate it down both edges of the polygon, and interpolate between the edges to get the value at the point of interest. Unfortunately, that requires doing a lot of work along each edge, and worse, requires division to calculate the 1/z step per pixel across each span.</p>
<p>A better solution is to calculate 1/z directly from the plane equation and the screen x and y of the pixel of interest. The equation is</p>
@ -40,7 +43,7 @@
<p>The full 1/z calculation requires two multiplies and two adds, all of which should be floating-point to avoid range errors. That much floating-point math sounds expensive but really isn&rsquo;t, especially on a Pentium, where a plane&rsquo;s 1/z value at any point can be calculated in as little as six cycles in assembly language.</p>
<h4 align="left" id="Heading10">Where That 1/Z Equation Comes From</h4>
<h4 id="Heading10">Where That 1/Z Equation Comes From</h4>
<p>For those who are interested, here&rsquo;s a quick derivation of the 1/z equation. The plane equation for a plane is</p>
@ -56,7 +59,7 @@
<p>We&rsquo;ll see 1/z sorting in action in Chapter 67.</p>
<h4 align="left" id="Heading11">Quake and Z-Sorting</h4>
<h4 id="Heading11">Quake and Z-Sorting</h4>
<p>I mentioned earlier that Quake no longer uses BSP order as the sorting key; in fact, it uses 1/z as the key now. Elegant as the gradients are, calculating 1/z from them is clearly slower than just doing a compare on a BSP-ordered key, so why have we switched Quake to 1/z?</p>
@ -70,16 +73,20 @@
<p>As I write this, it&rsquo;s unclear whether Quake will end up sorting edges by BSP order or 1/z. Actually, there&rsquo;s no guarantee that sorted spans in any form will be the final design. Sometimes it seems like we change graphics engines as often as they play Elvis on the &lsquo;50s oldies stations (but, one would hope, with more aesthetically pleasing results!) and no doubt we&rsquo;ll be considering the alternatives right up until the day we ship.</p>
<p><br /></p>
<center>
<table border="1">
<tr>
<td><a href="66-03.html">Previous</a></td>
<td>
<a href="66-03.html">Previous</a>
</td>
<td><a href="index.html">Table of Contents</a></td>
<td>
<a href="index.html">Table of Contents</a>
</td>
<td><a href="67-01.html">Next</a></td>
<td>
<a href="67-01.html">Next</a>
</td>
</tr>
</table>
</center>