Graphics Reference
In-Depth Information
Later on in Chapter 4 we shall derive a more general window-to-viewport transfor-
mation, but what we have now is good enough to do some simple two-dimensional
graphics programming.
1.6
Programming Notes
In the early years of the IBM PC and DOS and after there were some programming
languages such as PASCAL or C that had some basic graphics primitives built into the
language, it was fairly easy to describe what had to be done to write a graphics
program. It was a three-stage process. First, every such program had to enter “graph-
ics mode” when it started, then it could do all the graphics that it wanted, and finally
it had to leave graphics mode at the end and restore whatever mode the system was
in before the program started. Life has gotten much more complicated now that we
are in an age of graphical user interfaces (GUIs) and the Microsoft Windows operat-
ing system. Describing how one programs the graphics API for Microsoft Windows
would entail writing another topic. However, we do want to give the reader a flavor
of what is involved. To that end we present and discuss our only piece of low-level
graphics code in this topic. It shows how one would have used BGI code for the DOS
operating system.
As we just mentioned, the first thing that needed to be done in any graphics
program was to initialize both the hardware and certain global variables describing
this hardware to the program. Program 1.6.1 shows a very basic sample BGI C pro-
cedure, “InitializeGraphics,” which did this. The BGI procedure “initgraph” did the
initialization and returned the information about the hardware in use in its parame-
ters “graphDriver” and “graphMode.” The third parameter to the procedure was a DOS
path name to a directory where the BGI drivers were located. An empty string meant
that they were in the current directory. The function “graphresult” returned any error
that might have occurred and prevented the graphics system from being initialized.
A typical error was caused by the fact that the BGI driver was not located in the
current directory. The BGI drivers were files that came with the Borland program-
ming languages. Each contained hardware-specific code for the basic graphics prim-
itives and the one that matched one's hardware got linked into one's program.
After the graphics mode was initialized correctly, we then stored some useful
constants in global variables. The functions “getmaxx” and “getmaxy” returned the
maximum resolution of the screen in pixels in the horizontal and vertical direction,
respectively. The “textheight” and “textwidth” functions returned the height and width
of characters which one needs to determine the space required for text.
The “atexit” procedure passed the name of a procedure to call when the program
was done and was about to return to DOS. We have passed the name of the “MyEx-
itProc” procedure that calls the “closegraph” procedure. The latter switches from
graphics mode back to the standard 25 line and 80 column text mode (or whatever
mode the system was in before the program was called). Without the call to the “close-
graph” procedure the system would have been left in graphics mode with a messed-
up screen and would probably have had to be rebooted.
Assuming that the “InitializeGraphics” procedure executed without problems, one
would be in graphics mode and be presented with a blank screen. As indicated earlier,
