On 12.11.2006, at 09:44, Bart Botta wrote:
First suggestion is moving the function bindings to a separate package, and giving them lisp style names, so people like me who want to use them directly have supported access to them.
This is fine by me.
Second is changing the GLenums from cffi:defcenums to defconstants. Advantages I can think of from doing that:
This is not. The whole point of cl-opengl was having hand-written bindings that feel Lispy and not like a direct mapping to C. I do NOT want to write code like (gl:clear-color (logior gl:+color-buffer-bit+ gl:+depth- buffer-bit+)) or having to think about how to construct a foreign array to pass to glLightfv.
If somebody wants to use bindings like this, Glouton[1] or kt-opengl [2] seem like a better fit. They follow a different, more direct approach for people who prefer that model. Writing bindings isn't exactly rocket science, so having more than one way to do things is a good thing as far as I'm concerned.
*Easier for users to add enums from a new extension without modifying library code (unless cffi allows adding to an enum after it is defined, not sure about that)
This sounds like an easy addition to CFFI.
*Easier to add offsets to them, for example a loop to disable all lights could use (+ index gl:+light0+) instead of having to convert from enum and back, or store a list of the light enums or whatever. *being able to add offsets also solves the problem of some values (light in particular) potentially having more valid values than are enums. (The .spec files name 8 lights, but leaves room for 4096, I'm pretty sure there has been hardware supporting at least 32.)
The right way (IMHO) would be to have functionality in CFFI to add offsets to enums if desired, but there aren't that many places in OpenGL where this would even apply.
Off the top of my head, I can name GL_LIGHTi, GL_AUXi, GL_TEXTUREi, GL_CLIPPLANEi and GL_COLOR_ATTACHMENTi_EXT and I don't know a single graphics card whose limits exceed those defined in the spec/ headers, since a few of these are obsolete anyway thanks to programmable hardware.
You can see limits for most Macintosh graphics cards at http://homepage.mac.com/arekkusu/bugs/GLInfo.html
I /do/ agree that functions like GL:LIGHT should be able to take both a symbolic and a numeric identifer though, for the reasons you mentioned. But this can be done without ditching CFFI enums.
*compatibility with other bindings (glx and cl-sdl both use +foo+ style for enums if I remember correctly)
I neither care about GLX nor CL-SDL. If neither CLX, nor any other non-C library use +foo+, why should we? Personally, I think it looks way too ugly.
*possibly speed. If cffi can remap values at compile time it probably isn't too bad, but it probably wouldn't be too hard to find code with a lot of enums specified at runtime.
It does remap values where possible. Here's an example from OpenMCL:
? (defun foo () (gl:clear :color-buffer-bit :depth-buffer-bit)) FOO ? (disassemble 'foo) (TWNEI NARGS 0) (MFLR LOC-PC) (BLA .SPSAVECONTEXTVSP) (STWU SP -80 SP) (STW RZERO 8 SP) (LWZ ARG_Y '#<EXTERNAL-ENTRY-POINT "_glClear" (#x92E83368) /System/ Library/Frameworks/OpenGL.framework/OpenGL #x8476C8E> FN) (LWZ ARG_Z 2 ARG_Y) (TWEQI ARG_Z NIL) (VPUSH ARG_Z) (LI IMM0 16640) (STW IMM0 24 SP) (LWZ ARG_Z 0 VSP) (LA VSP 4 VSP) (BLA .SPPOWEROPEN-FFCALL) (LI ARG_Z NIL) (BA .SPPOPJ)
Note the LI IMM0 16640. GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT => 0x4100 => 16640.
But even then, the performance impact of doing so at runtime is neglible.
Also, a small patch: someone in #lisp was having problems with OpenMCL objecting to compute-applicable-methods being called with extra arguments in glut/interface.lisp, which was fixed by the following patch to define-glut-event:
diff -rN old-pct/glut/interface.lisp new-pct/glut/interface.lisp 130c130 < :func ',event-func :arg-count ,(length args))
:func ',event-func :arg-count ,(lengtharg-names))
Applied, thank you.
[1] http://common-lisp.net/project/glouton/ [2] Somewhere in http://common-lisp.net/project/cello/