OpenGL binding for Scheme

Sgl is distributed with PLT Scheme. The following excerpt is from the most recent version, distributed with version 299.28 and higher. Use PLT's help-desk to read the full documentation.

Sgl provides access to the system's GL library, version 1.5, and GLU library, version 1.3. The GL API and hence the sgl library do not address system level concerns, such as the attachment of GL rendering contexts to displays. The sgl library should work with any PLT Scheme extension that provides GL with access to the system (such as a binding for glx). DrScheme and mred automatically attach a GL rendering context to each canvas% object on (at least) Windows, Linux and OS X systems. Refer to the gears.ss example (${PLTHOME}/collects/sgl/examples/gears.ss) and the with-gl-context method on canvas% objects for more information on using the built-in GL rendering context support.

Sgl has two layers, gl.ss and sgl.ss. The gl.ss library provides access to the C-language-style GL API, whereas the sgl.ss library provides a more Scheme-like interface. The gl.ss library provides a binding for each #defined constant and for most functions in GL 1.5 and GLU 1.3. The functions perform comparable checking to their C-language counterparts; they check the types of their arguments, but do not check the length of array arguments. The sgl.ss library provides wrappers around many of the functions in the gl.ss library to present a more Scheme-friendly interface, including function names that follow Scheme conventions, and checked, symbolic enumeration arguments, and array-length checks.

Safety:
GL programming is inherently unsafe, even when using only the sgl.ss library. Although sgl.ss checks the arguments to each function call, violation of higher-level assumptions of the system's GL library can cause it to crash, bringing the entire Scheme system down. For example, sending a large number of vertices in a single glBegin causes at least some GL implementations to crash.