The World of Computer Software/World_Of_Computer_Software-02-385-Vol-1of3.iso/d/dots151.zip/GRAPHSRC.ZIP/G3.DOC

Text File | 1989-02-21 | 5KB | 119 lines

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.