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

70-08.html

@@ -24,7 +24,7 @@
 <!--CHAPTER=70//-->
 <!--PAGES=1291-1293//-->
 <!--UNASSIGNED1//-->
-<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
+<!--UNASSIGNED2//--></HEAD><body>
 
 <CENTER>
 <TABLE BORDER>
@@ -47,7 +47,7 @@
 <P>In the long run, it&rsquo;s cheaper to rewrite than to patch and modify!</P>
 <P>So as of shipping Quake, multiplayer performance was quite smooth, but latency was still a major issue, often in the 250 to 400 ms range for modem players. QuakeWorld attacked this in two ways. First, it reduced latency by around 50 to 100 ms with a server change. The Quake server runs 10 or 20 times a second, batching up inputs in between ticks, and sending out results after the tick. By contrast, QuakeWorld servers run immediately whenever a client sends input, knocking up to 50 or 100 ms off response time, although at the cost of a greater server processing load. (A similar anti-latency idea that wasn&rsquo;t implemented in QuakeWorld is having a separate thread that can send input off to the server as soon as it happens, instead of incurring up to a frame of latency.)</P>
 <P>The second way in which QuakeWorld attacks latency is by not interpolating. The player is actually predicted well ahead of the latest server packet (after all, the client has all the information needed to move the player, unless an outside force intervenes), giving very responsive control. The rest of the world is drawn as of the latest server packet; this is jerkier than Quake, again showing that smoothness is often a tradeoff for latency. The player&rsquo;s prediction may, of course, result in a minor paradox; for example, if an explosion turns out to have knocked the player sideways, the player&rsquo;s location may suddenly jump without warning as the server packet arrives with the correct location. In the latest version of QuakeWorld, the other players are predicted as well, with consequently more frequent paradoxes, but smoother, more convincing motion. Platforms and doors are still not predicted, and consequently are still pretty jerky. It is, of course, possible to predict more and more objects into the future; it&rsquo;s a tradeoff of smoothness and perceived low latency for the frustration of paradoxes&mdash;and that&rsquo;s the way it&rsquo;s going to stay until most people are connected to the Internet by something better than modems.</P>
-<H4 ALIGN="LEFT"><A NAME="Heading20"></A><FONT COLOR="#000077">Quake 2</FONT></H4>
+<H4 ALIGN="LEFT"><A NAME="Heading20"></A>Quake 2</H4>
 <P>I can&rsquo;t talk in detail about Quake 2 as a game, but I can describe some interesting technology features. The Quake 2 rendering engine isn&rsquo;t going to change that much from Quake; the improvements are largely in areas such as physics, gameplay, artwork, and overall design. The most interesting graphics change is in the preprocessing, where John has added support for radiosity lighting; that is, the ability to put a light source into the world and have the light bounced around the world realistically. This is sometimes terrific&mdash;it makes for great glowing light around lava and hanging light panels&mdash;but in other cases it&rsquo;s less spectacular than the effects that designers can get by placing lots of direct-illumination light sources in a room, so the two methods can be used as needed. Also, radiosity is <I>very</I> computationally expensive, approximately as expensive as BSPing. Most of the radiosity demos I&rsquo;ve seen have been in one or two rooms, and the order of the problem goes up tremendously on whole Quake levels. Here&rsquo;s another case where the PVS is essential; without it, radiosity processing time would be O(polygons<SUP>2</SUP>), but with the PVS it&rsquo;s O(polygons*average_potentially_visible_polygons), which is over an order of magnitude less (and increases approximately linearly, rather than as a squared function, with greater-level complexity).</P><P><BR></P>
 <CENTER>
 <TABLE BORDER>
@@ -61,7 +61,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 -->