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

Retidy, removing align=left from headings and empty paragraphs

Browse source
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
Download patch file Download diff file Expand all files Collapse all files

35
68-04.html
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,20 +18,24 @@
<center>
<table border="1">
<tr>
<td><a href="68-03.html">Previous</a></td>
<td>
<a href="68-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="69-01.html">Next</a></td>
<td>
<a href="69-01.html">Next</a>
</td>
</tr>
</table>
</center>
<p><br /></p>
<p>The amount of memory required for surface caching looked forbidding at first. Surfaces are large relative to texture tiles, because every texel of every surface is unique. Also, a surface can contain many texels relative to the number of pixels actually drawn on the screen, because due to perspective foreshortening, distant polygons have only a few pixels relative to the surface size in texels. Surfaces associated with partly hidden polygons must be fully built, even though only part of the polygon is visible, and if polygons are drawn back to front with overdraw, some polygons won&rsquo;t even be visible, but will still require surface building and caching. What all this meant was that the surface cache initially looked to be very large, on the order of several megabytes, even at 320x200&mdash;too much for a game intended to run on an 8 MB machine.</p>
<h4 align="left" id="Heading11">Mipmapping To The Rescue</h4>
<h4 id="Heading11">Mipmapping To The Rescue</h4>
<p>Two factors combined to solve this problem. First, polygons are drawn through an edge list with no overdraw, as I discussed a few chapters back, so no surface is ever built unless at least part of it is visible. Second, surfaces are built at four mipmap levels, depending on distance, with each mipmap level having one-quarter as many texels as the preceding level, as shown in Figure 68.4.</p>
@ -45,22 +48,26 @@
<p>Also, mipmapping is done on a per-surface basis; the mipmap level for a whole surface is selected based on the distance from the viewer of the nearest vertex. This led us to limit surface size to a maximum of 256x256. Otherwise, surfaces such as floors would extend for thousands of texels, all at the mipmap level of the nearest vertex, and would require huge amounts of surface cache space while displaying a great deal of aliasing in distant regions due to a high texel:pixel ratio.</p>
<h4 align="left" id="Heading12">Two Final Notes on Surface Caching</h4>
<h4 id="Heading12">Two Final Notes on Surface Caching</h4>
<p>Dynamic lighting has a significant impact on the performance of surface caching, because whenever the lighting on a surface changes, the surface has to be rebuilt. In the worst case, where the lighting changes on every visible surface, the surface cache provides no benefit, and rendering runs at the combined speed of surface building and texture mapping. This worst-case slowdown is tolerable but certainly noticeable, so it&rsquo;s best to design games that use surface caching so only some of the surfaces change lighting at any one time. If necessary, you could alternate surface relighting so that half of the surfaces change on even frames, and half on odd frames, but large-scale, constant relighting is not surface caching&rsquo;s strongest suit.</p>
<p>Finally, Quake barely begins to tap surface caching&rsquo;s potential. All sorts of procedural texturing and post-processing effects are possible. If a wall is shot, a sprite of pockmarks could be attached to the wall&rsquo;s data structure, and the sprite could be drawn into the surface each time the surface is rebuilt. The same could be done for splatters, or graffiti, with translucency easily supported. These effects would then be cached and drawn as part of the surface, so the performance cost would be much less than effects done by on-screen overdraw every frame. Basically, the surface is a handy repository for all sorts of effects, because multiple techniques can be composited, because it caches the results for reuse without rebuilding, and because the texels constructed in a surface are automatically drawn in perspective.</p>
<p><br /></p>
<center>
<table border="1">
<tr>
<td><a href="68-03.html">Previous</a></td>
<td>
<a href="68-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="69-01.html">Next</a></td>
<td>
<a href="69-01.html">Next</a>
</td>
</tr>
</table>
</center>