home *** CD-ROM | disk | FTP | other *** search
- NAME
- g31.c, g32.c, g3.h - portable Core System graphics package
-
- DESCRIPTION
- This is a portable implementation of the Core System graphics
- package intended for implementation on microcomputers with graphics
- approximately equivalent to the IBM PC. The Core System is
- described in Computer Graphics vol 13, no 3 (Aug 79), reprints of
- which are available from the Association for Computing Machinery
- (item number 428791). You can call ACM at 1-800-526-0359, ext.
- 75, to order a copy.
-
- I chose to implement the Core System because it was designed from
- the ground up to be a three dimensional standard (unlike GKS, for
- example).
-
- Three classes of upward compatible levels are specified for Core
- Systems; one class for output, one class for input, and one class
- concerning dimensionality. This implementation has:
-
- Output level 1: basic output
-
- There are no retained segments or image transformations
- (not to be confused with viewing transformations, which
- are of course provided). Of the text primitives, only
- text() is provided, and text is generated only in
- "string_precision" (CHARPLANE, CHARUP, CHARPATH, and
- CHARSPACE not implemented). This means that strings
- are always displayed from left to right, and there are
- no tilted characters.
-
- Input level 1: no input
-
- A simple cursor key interface is provided.
-
- Dimension level 2: three dimensional
-
- All 2D and 3D viewing transformations are provided.
-
- Some inquiry and setting functions have not been implemented - for
- example, set_viewing_parameters(viewing_parameter_array). Some viewing
- operation functions may still follow the definitions in the 1977 draft
- of the Core System.
-
- None of the "raster extensions" have been implemented.
-
- USAGE
- A program using G3 consists of three layers of software. First is the
- application software, which interacts with the user, reads data, and
- generates an image in "world coordinates" using calls to the output
- primitives. Second is the Core System graphics package itself
- (files G31.C and G32.C) which converts the image from world
- coordinates (doubles) to screen coordinates (integers). The third
- layer deals with the graphics hardware and is therefore machine
- dependent.
-
- One way to structure the application program is as follows:
-
- <read_data>
- <initialize>
- do {
- <specify coordinate transformation>
- <open segment>
- <generate image>
- <close segment>
- <get input from user>
- } while (not_finished);
- <terminate>
-
- For examples, see GRAPH, DOTS, and GLOBE.
-
- IMPLEMENTATION
- This package was written for the DeSmet C compiler. G31 and G32 are
- entirely in C, and are not known to depend on the operating system.
- The interface routines such as GPC and GZ are partly assembly
- language, which the DeSmet compiler permits to be intermingled with
- the C code. They require MS-DOS 2.0 or higher (because of their
- use of the environment).
-
- This implementation was written with approximately these priorities:
- (1) correctness (freedom from visible glitches), (2) speed, and (3)
- functionality.
-
- This package requires a set of interface variables and
- functions for each machine. I've written these device drivers
- for CGA, EGA, and Hercules adaptors on an IBM, the Zenith
- Z-100, the Houstin Instruments DMP-29 and Hewlett Packard 7470A
- plotters, Postscript, and the CIE LIPS-10 laser printer. Some
- of these drivers implement more than one graphics modes. The
- user chooses among modes by setting the environment variable
- GRAPHICS to a number. Similarly, the environment variable
- PLOT_PORT has the name of the output port for a plotter or
- printer. I chose that method so the application software would
- remain ignorant of the existence of multiple modes. (This does
- mean that the application software should initialize the
- graphics before using any of the variables declared in G.H.) An
- alternative would be to put equivalent data into a
- configuration file.
-
- I'd be glad to work with anyone who wants to port the package
- onto other computers or other compilers. Anyone attempting
- this for a display screen should use BENCH to verify their
- implementation.
-
- There are many things I haven't implemented. I'd especially
- like to see some of the raster extensions, like area fill and
- hidden line removal. Note - the Core System package currently
- does not require the line erase function. It will require that
- function if is extended to include retained segments. If no
- line erase function is defined, the variable erase_line should
- be set to point to the line drawing routine.
-
- AUTHOR
- Copyright (c) 1985 - 1989 by James R. Van Zandt
- (jrv@mitre-bedford) 27 Spencer Dr., Nashua NH 03062, 603-888-2272.
- Resale forbidden, copying for personal use encouraged.
- Constructive comments welcome.
-
-