Graphics Reference
In-Depth Information
and use basic windowing operations, one has to initialize OpenGL and DirectX in a
separate step.
After a program has initialized the graphics hardware, the next step is to decide
how to lay out the screen. Where should graphics output go? Where to put the menus?
What about an area for getting feedback from the user and printing system-related
messages? Topics have been written on what makes for a good graphical user inter-
face. See [Pedd92] for example. Microsoft has its own recommendations for programs
that run in its Windows environment. See [Micr94].
One thing is clear though about today's GUIs. They take an awful lot of code and
time to develop. Even if one does not start from scratch and one uses the typical APIs
one gets when developing for an environment like Windows, it still requires quite a
bit of understanding about the underlying architecture to use them effectively. For
that reason, when this author has taught graphics classes he always, since the days
of DOS, provided the students with a program similar to the current GM program
that can be found on the accompanying CD. Its interface, described in the document
GmGUI which is also on the CD, allowed both mouse and keyboard input and made
it easy for students to add menus. In this way the students did not have to spend any
time developing this interface and could concentrate on implementing the various
algorithms described in the topic. The current Windows version of GM is also such
that students do not need to have any prior knowledge of Windows or C++. (They obvi-
ously do have to know how to program in C.) A couple of lectures at the beginning
of the semester and another one or two later on to describe some additional features
was all that was necessary. Of course, if one wants to make use of OpenGL, then this
takes extra time.
The GM program already comes with quite a bit of functionality built into it. This
means that some of the programming projects at the end of the chapters in this topic,
in particular some of the basic ones in the early chapters such as this one, have already
been implemented either implicitly or explicitly. Readers who are new to graphics pro-
gramming should ignore this fact and will find it very instructive to develop the
required code on their own. They can then compare their solutions with the ones in
the GM program. It is when one gets to more advanced projects that building on the
GM program would be appropriate.
Finally, this topic will not get into any device-dependent issues and all the algo-
rithms and code will be analyzed and presented at a higher level than that. Except for
the BGI example above, we present no actual code but shall use a fairly standard
abstract program syntax (pseudocode) described in Appendix B. We shall also not use
any actual API when discussing abstract algorithms, but, if needed, use the following
set of graphics primitives:
(The points and rectangles below are assumed to be in the raster, that is, they are
specified by integer coordinates. Rectangles are specified by two points, the top left
and bottom right corner. By a rectangle we mean the border only, not the interior.)
SetMode (MODE)
(sets “current” mode to MODE, where MODE is a
bit operation such as xor or replace )
SetColor (COLOR)
(sets “current” color to COLOR)
Draw (point or rectangle)
(in “current” color and mode)
Erase (point or rectangle)
(draws in “background” color)
Search WWH ::




Custom Search