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

Normal quotes

Browse source
This commit is contained in:
James Gregory 2013-12-30 18:34:31 +11:00
commit 18011c595a
352 changed files with 6040 additions and 6040 deletions
Download patch file Download diff file Expand all files Collapse all files

26
53-04.md
View file

@ -6,7 +6,7 @@
/* Object list-related functions. */
#include <stdio.h>
#include “polygon.h”
#include "polygon.h"
/* Set up the empty object list, with sentinels at both ends to
terminate searches */
@ -90,17 +90,17 @@
FIXED.ASM contains the equate **ROUNDING-ON**. When this equate is 1,
the results of multiplications and divisions are rounded to the nearest
fixed-point values; when it’s 0, the results are truncated. The
fixed-point values; when it's 0, the results are truncated. The
difference between the results produced by the two approaches is, at
most, 2^-16^; you wouldn’t think that would make much difference, now,
most, 2^-16^; you wouldn't think that would make much difference, now,
would you? But it does. When the animation is run with rounding
disabled, the cubes start to distort visibly after a few minutes, and
after a few minutes more they look like they’ve been run over. In
contrast, I’ve never seen any significant distortion with rounding on,
after a few minutes more they look like they've been run over. In
contrast, I've never seen any significant distortion with rounding on,
even after a half-hour or so. I think the difference with rounding is
not that it’s so much more accurate, but rather that the errors are
not that it's so much more accurate, but rather that the errors are
evenly distributed; with truncation, the errors are biased, and biased
errors become very visible when they’re applied to right-angle objects.
errors become very visible when they're applied to right-angle objects.
Even with rounding, though, the errors will eventually creep in, and
reorthogonalization will become necessary at some point.
@ -115,17 +115,17 @@ rounding for division.
#### Having a Ball {#Heading7}
So far in our exploration of 3-D animation, we’ve had nothing to look at
but triangles and cubes. It’s time for something a little more visually
So far in our exploration of 3-D animation, we've had nothing to look at
but triangles and cubes. It's time for something a little more visually
appealing, so the demonstration program now features a 72-sided ball.
What’s particularly interesting about this ball is that it’s created by
What's particularly interesting about this ball is that it's created by
the GENBALL.C program in the BALL subdirectory of X-Sharp, and both the
size of the ball and the number of bands of faces are programmable.
GENBALL.C spits out to a file all the arrays of vertices and faces
needed to create the ball, ready for inclusion in INITBALL.C. True, if
you change the number of bands, you must change the Colors array in
INITBALL.C to match, but that’s a tiny detail; by and large, the process
of generating a ball-shaped object is now automated. In fact, we’re not
INITBALL.C to match, but that's a tiny detail; by and large, the process
of generating a ball-shaped object is now automated. In fact, we're not
limited to ball-shaped objects; substitute a different vertex and face
generation program for GENBALL.C, and you can make whatever convex
polyhedron you want; again, all you have to do is change the **Colors**
@ -138,7 +138,7 @@ GENBALL.C is the prototype for object definition, and INITBALL.C is the
prototype for general-purpose object instantiation. Certainly, it would
be nice to someday have an interactive 3-D object editing tool and
resource management setup. We have our hands full with the drawing end
of things at the moment, though, and for now it’s enough to be able to
of things at the moment, though, and for now it's enough to be able to
create objects in a semiautomated way.
------------------------ --------------------------------- --------------------