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
