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-04.html">Previous</a></td>
<td>
<a href="66-04.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-02.html">Next</a></td>
<td>
<a href="67-02.html">Next</a>
</td>
</tr>
</table>
</center>
<p><br /></p>
<h2 id="Heading1">Chapter 67<br />
Sorted Spans in Action</h2>
@ -57,16 +60,20 @@
<p>That wasn&rsquo;t the bad part; after all, even a small speed increase is A Good Thing. The real problem was that our initial 1/z sorting proved to be unreliable. We first ran into problems when two forward-facing polygons started at a common edge, because it was hard to tell which one was really in front (as discussed below), and we had to do additional floating-point calculations to resolve these cases. This fixed the problems for a while, but then odd cases started popping up where just the right combination of polygon alignments caused new sorting errors. We tinkered with those too, adding more code and incurring additional slowdowns in the process. Finally, we had everything working smoothly again, although by this point Quake was back to pretty much the same speed it had been with BSP sorting.</p>
<p><br /></p>
<center>
<table border="1">
<tr>
<td><a href="66-04.html">Previous</a></td>
<td>
<a href="66-04.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-02.html">Next</a></td>
<td>
<a href="67-02.html">Next</a>
</td>
</tr>
</table>
</center>