PC graphics standards

[Peter Nelson]

   In porting my QuickC programs over to Zortech, the main
   thing I noticed, besides a lot of compiler bugs disappearing,
   was that the only thing I had to rewrite was the graphics
   routines.  Everything else compiled and ran with no difficulties.

   Most of my programs are graphics-intensive so having to do this
   every time I change compilers is a pain.  [ For one thing, it means
   I have to read the manual 8-) .  ]
                               
   I'm not real familiar with what passes for graphics in the PC
   world.   With workstations you can generally assume that you'll
   have 1280 X 1024 with 24, 40, 80 (or sometimes more) bits per pixel
   and if you want portability you can use the manufacturer's PHIGS,
   GKS or X-windows (the latter obviously being more than a graphics
   standard).  Even the workstation world has a long way to go
   in supporting more sophisticated rendering models, though there
   seems to be growing support for PHIGS+.

   But things seem to be a little crazier in the PC world.  There
   is an absurd lack of standards for the hardware.  CGA, HGA, EGA, 
   and a random number of flavors of VGA complicate things.  And since
   even the *best* VGA graphics are toylike compared to workstations, 
   I'm sure we'll see newer standards down the road. Of course,
   workstations have no hardware standards for graphics either,
   but at least there the hardware maker also supplies the software
   tools like compilers and PHIGS libraries, so he supplies the
   drivers for his own devices.  

   Most of the things that the the various compiler's C graphics
   libraries do are practically the same:   Set a point, draw a line,
   draw an arc, draw a circle, draw a rectangle, fill a region, 
   set clipping limits, clear the screen, set a color, put up 
   some text, and perhaps a few other similar primitive functions.
   None of the ones I've seen try to do anything fancy like NURBS,
   homogeneous transforms, hidden surface removal, lighting models,
   or display lists, although I'm sure these are all available as
   expensive 3rd party products.

   So given that PC C compiler graphics offer similar, and generally 
   primitive, kinds of functions, why do they do them so differently?
   If the compiler writers can agree on other library features, even ones
   like kbhit() which are not blessed by ANSI, why can't they do the
   same for graphics primitives?

   Anyway, given that they can't, what are some alternatives?  Does
   anyone know any good implementations of PHIGS, HOOPS, or GKS with
   a C binding for PC's?  What are some other approaches to writing 
   compiler- and device- independent graphics code for PC's?   


                                                          ---Peter