Hi all,
I propose the following patch to implement the remaining state query functions (glGetInteger, glGetBoolean, etc) in CL-OPENGL. The interface is pretty straightforward, and the user can omit the number of values to return when the query is known to the library.
For example (from a running OpenGL program):
CL-USER> (gl:get-float :viewport) #(0.0 0.0 640.0 480.0) CL-USER> (gl:get-float :texture-matrix) #(1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0 0.0 0.0 0.0 0.0 1.0) CL-USER> (gl:get-boolean :blend) T CL-USER> (gl:get-enum :depth-func 'gl::compare-func) :LESS
I'm becoming fairly convinced that the separation of GLenum into discrete enum types based on context may not be a good idea. OpenGL doesn't make any distinction between different types of enums, and it feels as though we are going against the grain trying to separate them.
There are a lot of duplicate definitions, and it also makes it hard to deal with a case like glGetInteger where you want to say, "this function returns a GLenum", because you don't know which CL-OPENGL enum type to use (hence the additional argument to GL:GET-ENUM in my implementation).
I'd be willing to do the grunt work on a patch to move to one unified enum type---hopefully such a beast could be mostly machine generated from a header file or specification document (and updated by hand from then on).
James