[cl-opengl-devel] gl 3.2

Bart Botta 00003b at gmail.com
Fri Sep 18 15:56:07 UTC 2009


I've updated my fork to gl 3.2 and latest extensions as of 2009-09-11
(GL_EXT_VERSION 55), and merged it with the current darcs tree :

http://github.com/3b/cl-opengl

In addition to updating to current GL version, this tree has automatic
GL error checking, which can be disabled at by pushing
:cl-opengl-no-check-error onto *features* before compiling cl-opengl
(calling code must be recompiled too, since the functions are
declaimed inline.)

Due to duplicated names in %gl:enum, gl:get-error,
gl:check-framebuffer-status, and gl:check-framebuffer-status-ext (and
a few other functions that i don't think existed in the main tree
anyway) return :unsigned-int instead of %gl:enum now, so some existing
code might break with this tree. There is currently gl::enum= for
comparing %gl:enum values to the numerical values, and to each other
by value. Not sure if that is the final API or not yet, so feedback on
whether that is enough for actual usage or not would be good.

other features/changes:

gl:get* - for known queries, determines number and type of value(s) to
return automatically. Should know about everything through gl 3.0 or
so, but may not be completely current. Needs a better name, so that
might change...

uses cffi:bitfields for various arguments, so the short names (without
the -bit suffix) don't conflict with other enums, probably not visible
to most user code that wasn't running into the conflicts, but anything
dealing with the values directly might need modified.

various bugfixes, export more %gl: functions from gl:, etc.

Unlike my previous gl3 fork, this one doesn't try to split out the
core/non-deprecated parts of the GL spec, so it should be easier to
keep up to date with newer GL versions/extensions. It also doesn't
close glut windows on errors, since that broke the
glut:*run-main-loop-after-display* feature used by
cl-glut-examples:run-examples, not sure what the correct way to handle
that is.

This tree hasn't been tested much beyond sbcl/linux/x86_64, so more
testing would be welcome.

-b-




More information about the cl-opengl-devel mailing list