Graphics Reference
In-Depth Information
find that you
need
to be clever. Second, we've used names for all the important
things that we might consider changing, like
xmin
and
nEdges
. That's because
most test programs like this one survive far longer than originally intended, and
get altered for other uses; symbolic names help us communicate with our former
selves (who wrote the program originally). Third, the program is not “software
engineered”: We didn't define a class to represent general shapes, for instance—
we just used an array of a fixed size to represent one shape, the cube. That was
deliberate. The program was meant to be used, experimented with, and thrown
away (or perhaps reused in another experiment). The point of this program was to
verify our understanding of a simple concept. It's not a prototype for some large-
scale project. Indeed, if you find yourself building something of even a modest
scale atop this framework, you're making a big mistake: The pieces of this frame-
work were designed to make testing and debugging easy. If you run the program
and place your cursor over one of the dots, for instance, a tool-tip will appear
telling you the dot's coordinates; the same goes for the edges. That makes sense
when you're debugging, but by the time you're drawing 10,000 edges, it's a huge
amount of overhead. Remember that this framework is a test bed for experiments,
and that all the code you write within it should be considered disposable. While
this advice may seem contradictory—we've said to throw away code, but to code
decently because you'll be reusing it—it reflects our experience: Even code we
intend to throw away
does
get reused, often for other throwaway applications!
It's worth investing a little time to make these future uses easier, but not worth
investing so much that it takes hours to code up a simple idea and confirm your
understanding.
The results are what we expect (see Figure 3.8): a perspective picture of a wire-
frame cube. We've created our first rendering! There's clearly a long way to go
Figure 3.8: The result of the Dürer program: a wire-frame cube, shown in perspective, on
a background that looks like graph paper. The axes on the graph paper are part of the
GraphPaper
itself, set up by the test bed, and are not drawn by the Dürer rendering part
of the program.
