
		      OPENGL/MESA Bindings for SCHEME->C

These bindings allow calls to OPENGL/MESA functions from SCHEME->C.  You can
use GL calls (and XLIB calls) from a scheme interpreter (SCIGL), or you can
build stand-alone programs.

These bindings are specialized to SCHEME->C.  It should be possible to modify
them, but I have not tried.  In addition, these bindings have only been tested
with MESA and not with OPENGL.

If you use these routines, please let me know by Email.  In particular, I want
to know how many people are using SCHEME->C (or any other Scheme) for graphics
and application programming.

Thanks,

Richard Mann
mann@cs.toronto.edu
10 October 1996


				    FILES

makefile    	Edit this to conform to your system.  You need to say where
    	    	to find the SCHEME->C distribution, OPENGL/MESA includes and
    	    	libraries, and the XLIB includes and libraries.

gl.sc	    	Binds to GL.  Contains bindings to all C functions in
    	    	GL.H and GLX.H.
gl.sch	    	Prototypes for gl.sc.

xlib.sch    	Prototype for XLIB.H  (Includes prototypes from SCHEME->C
    	    	distribution.)

c-array.sc	Accessors to C-arrays.  Used to transfer raw data to and
    	    	from GL functions.
c-array.sch 	Prototypes for c-array.sc.

gl-spin.sc  	Sample program (modeled after spin.c from Mesa distribution).
gl-xdemo.sc 	Sample program (modeled after glxdemo.c from Mesa).


				 INSTALLATION

0. You need to have a SCHEME->C source distribution with the XLIB interface
   built.

1. Edit the makefile to conform to your system.

2. To build a version of "SCI" interpreter with GL and Xlib bindings:
    % make scigl

3. To run program from interpreter
    % scigl
    > (load "<program>.sc")
    > (main '())

   Sample programs are "gl-spin.sc" and "gl-xdemo.sc".

4. To compile programs
    % make <program>


			      NOTES/LIMITATIONS

I provide bindings only for GL and GLX.  There are no bindings (yet) for GLU.

In addition, there are no bindings for GLTK or GLAUX.  Since there are no
callbacks in Scheme, I use a low-level XLIB interface to do the event loops.
(If anyone knows how to use GLTK or GLAUX from Scheme, please let me know!)

A note about datatypes.  As with the SCHEME->C XLIB bindings, all datatypes
are either immediate (strings, integer, float, etc) or pointers.  Pointers are
stored as `dotted pairs', where (CAR X) a symbol denoting the type, (CDR X) is
the data.  The type of the pointer may be specified (such as "DISPLAY") or it
may be generic.  Generic objects always have the type "POINTER".  While some
of the routines check for the data type, most do not; they merely take the CDR
of the object and use it as a pointer.  (Full type checking may be added
later.)

The data can be either a string or a pointer.  Pointers will generally be used
when the data is allocated by a C function, while strings will generally be
used when the data is allocated by a Scheme function (or a Scheme wrapper
around a C function).  Note that some routines (like <TYPE>-ARRAY-LENGTH in
C-ARRAY.SC) depend on the data being of type string (so the length of the
allocated data can be determined).  These will fail if the data field is a
pointer.  Except for a few functions (like ARRAY-LENGTH mentioned above), to
be compatable with all sorts of interfaces, I allow either a string or a
pointer type in the data field.

These bindings have only been used with MESA.  I have not tried them with
OPENGL.  In addition, not many of the GL/GLX functions have been tested.  I
suspect some functions that try to access pointer types and string types may
be incorrect and/or unsuitable.

The example programs are messy.  Sometimes (eg., in GL-XDEMO.SC) the XLIB
calls in Scheme seem to behave differently than the XLIB calls in C.  X errors
may result.  I have not figured out how to fix these.  Also note that some of
the XLIB calls in SCHEME->C have slightly different names/calling conventions
than the C calls.

When compiling stand-alone applications, big executables are generated.  This
is for two reasons.  First, I am linking statically to the OPENGL/MESA
library.  Second, the file GL.SC causes *all* functions in GL and GLX to be
included in the executable.  Ideally I should split the file GL.SC into
several pieces so only those parts needed are included.


			       ACKNOWLEDGEMENTS

The original bindings were generated using (a modified version of) FFIGEN from
Lars Thomas Hansen (lth@cs.uoregon.edu).
