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

Strip comments and inline ids onto h*

Browse source
This commit is contained in:
James Gregory 2013-12-30 15:11:04 +11:00
commit 0f5f617adb
362 changed files with 2519 additions and 6694 deletions
Download patch file Download diff file Expand all files Collapse all files

19
52-08.html
View file

@ -10,16 +10,9 @@
<meta name="vspubdate" content="07/01/97" />
<meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Fast 3-D Animation: Meet X-Sharp</title><!-- HEADER -->
<!-- Empty Reference Subhead -->
<!--ISBN=1576101746//-->
<!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
<!--AUTHOR=Michael Abrash//-->
<!--PUBLISHER=The Coriolis Group, Inc.//-->
<title>Michael Abrash's Graphics Programming Black Book Special Edition: Fast 3-D Animation: Meet X-Sharp</title>
<meta name="chapter" content="52" />
<meta name="pages" content="985-987" />
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//-->
</head>
<body>
@ -45,13 +38,13 @@
<p>Just for fun, I reimplemented the animation of Listings 52.1 through 52.10 with floating-point instructions. Together, the preceeding optimizations improve the performance of the entire animation&mdash;including drawing time and overhead, and not just math&mdash;by more than ten times over the code that uses the floating-point emulator. Amazing what one can accomplish with a few dozen lines of assembly and a switch in number format, isn&rsquo;t it? Note that no assembly code other than the native 386 multiply and divide is used in Listings 52.1 through 52.10, although the polygon fill code is of course mostly in assembly; we&rsquo;ve achieved 12 cubes animated at 15 fps while doing the 3-D work almost entirely in Borland C++, and we&rsquo;re <i>still</i> doing sine and cosine via the floating-point emulator. Happily, we&rsquo;re still nowhere near the upper limit on the animation potential of the PC.</p>
<h4 align="left"><a id="Heading6"></a>Drawbacks</h4>
<h4 align="left" id="Heading6">Drawbacks</h4>
<p>The techniques we&rsquo;ve used to turbocharge 3-D animation are very powerful, but there&rsquo;s a dark side to them as well. Obviously, native 386 instructions won&rsquo;t work on 8088 and 286 machines. That&rsquo;s rectifiable; equivalent multiplication and division routines could be implemented for real mode and performance would still be reasonable. It sure is nice to be able to plug in a 32-bit <b>IMUL</b> or <b>DIV</b> and be done with it, though. More importantly, 32-bit fixed-point arithmetic has limitations in range and accuracy. Points outside a 64Kx64Kx64K space can&rsquo;t be handled, imprecision tends to creep in over the course of multiple matrix concatenations, and it&rsquo;s quite possible to generate the dreaded divide by 0 interrupt if Z coordinates with absolute values less than one are used.</p>
<p>I don&rsquo;t have space to discuss these issues in detail, but here are some brief thoughts: The working 64Kx64Kx64K fixed-point space can be paged into a larger virtual space. Imprecision of a pixel or two rarely matters in terms of display quality, and deterioration of concatenated rotations can be corrected by restoring orthogonality, for example by periodically calculating one row of the matrix as the cross-product of the other two (forcing it to be perpendicular to both). Alternatively, transformations can be calculated from scratch each time an object or the viewer moves, so there&rsquo;s no chance for cumulative error. 3-D clipping with a front clip plane of -1 or less can prevent divide overflow.</p>
<h4 align="left"><a id="Heading7"></a>Where the Time Goes</h4>
<h4 align="left" id="Heading7">Where the Time Goes</h4>
<p>The distribution of execution time in the animation code is no longer wildly biased toward transformation, but sine and cosine are certainly still sucking up cycles. Likewise, the overhead in the calls to <b>FixedMul()</b> and <b>FixedDiv()</b> is costly. Much of this is correctable with a little carefully crafted assembly language and a lookup table; I&rsquo;ll provide that shortly.</p>
@ -74,10 +67,6 @@
<div align="center">
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->
<!-- reference_footer = subfoot -->
<!-- BEGIN SUB FOOTER -->
<!-- END FOOTER -->
</div>
</body>
</html>