nelson_p@apollo.HP.COM (Peter Nelson) (02/23/90)
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