home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD2.mdf / c / library / dos / grafik / coregraf / g3.doc < prev    next >
Encoding:
Text File  |  1986-01-06  |  4.2 KB  |  97 lines
  1. NAME
  2.     g31.c, g32.c, g3.h - portable Core System graphics package
  3.  
  4. DESCRIPTION
  5.     This is a portable implementation of the Core System graphics package
  6.     intended for implementation on microcomputers with graphics
  7.     approximately equivalent to the IBM PC.  The Core System is described
  8.     in Computer Graphics vol 13, no 3 (Aug 79), reprints of which are
  9.     available from the Association for Computing Machinery (item number
  10.     428791).  You can call ACM at 1-800-526-0359, ext.  75, to order a
  11.     copy.
  12.  
  13.     Three classes of upward compatible levels are specified for Core
  14.     Systems; one class for output, one class for input, and one class
  15.     concerning dimensionality.  This implementation has:
  16.  
  17.         Output level 1: basic output
  18.  
  19.             There are no retained segments or image transformations
  20.             (not to be confused with viewing transformations, which
  21.             are of course provided).  Of the text primitives, only
  22.             text() is provided, and text is generated only in
  23.             "string_precision" (CHARPLANE, CHARUP, CHARPATH, and
  24.             CHARSPACE not implemented).  This means that strings
  25.             are always displayed from left to right, and there are
  26.             no tilted characters.
  27.  
  28.         Input level 1: no input
  29.  
  30.             A simple cursor key interface is provided.
  31.  
  32.         Dimension level 2: three dimensional
  33.  
  34.             All 2D and 3D viewing transformations are provided.
  35.  
  36.     Some inquiry and setting functions have not been implemented - for
  37.     example, set_viewing_parameters(viewing_parameter_array).  Some viewing
  38.     operation functions may still follow the definitions in the 1977 draft
  39.     of the Core System.
  40.  
  41.     None of the "raster extensions" have been implemented.
  42.  
  43. USAGE
  44.     A program using G3 consists of three layers of software.  First is the
  45.     application software, which interacts with the user, reads data, and
  46.     generates an image in "world coordinates" using calls to the output
  47.     primitives.  Second is the Core System graphics package itself (files
  48.     G31.C and G32.C) which converts the image from world coordinates
  49.     (doubles) to screen coordinates (integers) and calls the third layer,
  50.     which deals with the graphics hardware and is therefore machine
  51.     dependent.
  52.  
  53.     One way to structure the application program is as follows:
  54.  
  55.         <read_data>
  56.         <initialize>
  57.         do    {<generate image>
  58.             <get input from user>
  59.             }
  60.         while (not_finished);
  61.         <terminate>
  62.  
  63. IMPLEMENTATION
  64.     This package was written for the DeSmet C compiler.  G31 and G32 are
  65.     entirely in C, and are not known to depend on the operating system. 
  66.     The interface routines GPC and GZ are partly assembly language, which
  67.     the DeSmet compiler permits to be intermingled with the C code.  They
  68.     require MS-DOS 2.0 or higher (because of their use of the environment).
  69.  
  70.     This implementation was written with approximately these priorities:
  71.     (1) correctness (freedom from visible glitches), (2) speed, and (3)
  72.     functionality.
  73.  
  74.     This package requires a set of interface variables and functions for
  75.     each machine.  I've written interfaces for the IBM PC and Z-100.  Each
  76.     of these interfaces implements two separate graphics modes.  The user
  77.     chooses between modes by setting the environment variable GRAPHICS to a
  78.     number.  I chose that method so the application software would remain
  79.     ignorant of the existence of multiple modes.  (This does mean that the
  80.     application software should initialize the graphics before using any of
  81.     the variables declared in G.H.) An alternative would be to put
  82.     equivalent data into a configuration file.
  83.  
  84.     I'd be glad to work with anyone who wants to port the package onto
  85.     other computers or other compilers, or to add the things I haven't
  86.     implemented.  I'd especially like to see some of the raster extensions,
  87.     like area fill and hidden line removal.  Note - the Core System package
  88.     currently does not require the line erase function.  It will require
  89.     that function if is extended to include retained segments.  If no line
  90.     erase function is defined, the variable erase_line should be set to
  91.     point to the line drawing routine.
  92.  
  93. AUTHOR
  94.     Copyright (c) 1985 by James R.  Van Zandt (jrv@mitre-bedford)
  95.     27 Spencer Dr., Nashua NH 03062, 603-888-2272.  Resale
  96.     forbidden, copying for personal use encouraged.  Constructive
  97.     comments welcome.