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

33
53-03.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,17 +18,21 @@
<center>
<table border="1">
<tr>
<td><a href="53-02.html">Previous</a></td>
<td>
<a href="53-02.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="53-04.html">Next</a></td>
<td>
<a href="53-04.html">Next</a>
</td>
</tr>
</table>
</center>
<p><br /></p>
<h3 id="Heading4">Raw Speed, Part II: Look it Up</h3>
<p>It&rsquo;s a funny thing about Turbo Profiler: Time spent in the Borland C<small>++</small> 80x87 emulator doesn&rsquo;t show up directly anywhere that I can see in the timing results. The only way to detect it is by way of the line that reports what percent of total time is represented by all the areas that were profiled; if you&rsquo;re profiling all areas, whatever&rsquo;s not explicitly accounted for seems to be the floating-point emulator time. This quirk fooled me for a while, leading me to think sine and cosine weren&rsquo;t major drags on performance, because the <b>sin()</b> and <b>cos()</b> functions spend most of their time in the emulator, and that time doesn&rsquo;t show up in Turbo Profiler&rsquo;s statistics on those functions. Once I figured out what was going on, it turned out that not only were <b>sin()</b> and <b>cos()</b> major drags, they were taking up over half the total execution time by themselves.</p>
@ -38,7 +41,7 @@
<p>FIXED.ASM (Listing 53.1) speeds X-Sharp up quite a bit, and it changes the performance balance a great deal. When we started out with 3-D animation, calculation time was the dragon we faced; more than 90 percent of the total time was spent doing matrix and projection math. Additional optimizations in the area of math could still be made (using 32-bit multiplies in the backface-removal code, for example), but fixed-point math, the sine and cosine lookup, and selective assembly optimizations have done a pretty good job already. The bulk of the time taken by X-Sharp is now spent drawing polygons, drawing rectangles (to erase objects), and waiting for the page to flip. In other words, we&rsquo;ve slain the dragon of 3-D math, or at least wounded it grievously; now we&rsquo;re back to the dragon of polygon filling. We&rsquo;ll address faster polygon filling soon, but for the moment, we have more than enough horsepower to have some fun with. First, though, we need one more feature: hidden surfaces.</p>
<h4 align="left" id="Heading5">Hidden Surfaces</h4>
<h4 id="Heading5">Hidden Surfaces</h4>
<p>So far, we&rsquo;ve made a number of simplifying assumptions in order to get the animation to look good; for example, all objects must currently be convex polyhedrons. What&rsquo;s more, right now, objects can never pass behind or in front of each other. What that means is that it&rsquo;s time to have a look at hidden surfaces.</p>
@ -53,16 +56,20 @@
<p><a id="Fig1"><img src="images/53-01.jpg" /><br />
<b>Figure 53.1</b></a>&nbsp;&nbsp;<i>Why back-to-front sorting doesn&rsquo;t always work properly.</i></p>
<p><br /></p>
<center>
<table border="1">
<tr>
<td><a href="53-02.html">Previous</a></td>
<td>
<a href="53-02.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="53-04.html">Next</a></td>
<td>
<a href="53-04.html">Next</a>
</td>
</tr>
</table>
</center>