[cl-opengl-devel] generating function bindings, extension loading

[Oliver Markovic]

(gah, I always forget to hit "Reply All")

On 12.11.2006, at 14:51, Bart Botta wrote:

> I'm not arguing that the behavior of the hand written API should
> change*, just the shape of the parameters. gl:clear still handles
> combining the arguments, it just uses logior instead of make-bitfield.
>
> *(well, actually, I might argue that the API should change, but if I
> did, the argument would be that cl-opengl is too low level, not that
> it should be closer to the C API :)

Well, I don't see any significant advantage in doing so.


> Or my bindings if I release them, I was just hoping to have that
> behavior as a subset of cl-opengl to avoid pointless forks :)

It's not pointless fork if it wants to do things differently. This  
project was
originally made to collaborate with Luis Oliveira on writing Lispy  
OpenGL
bindings that suit our personal needs. Nothing more.

As I said, writing bindings is not rocket science and one could  
generate a
simple set in an afternoon if desired, so I do not see any harm in  
having more
than one.


> I was thinking more of workstation level cards, 3dlabs realizm, etc.
> http://www.delphi3d.net/hardware/viewreport.php?report=1503
>
> Easy enough to just add more enums to cover the extra if you stay with
> cffi enums, so it isn't too much of a problem.

Well yeah, it wasn't meant to be dismissive, just that I don't see it  
as a big problem
that would justify switching to defconstants. It's easy to switch  
those few functions
to accept integers instead of enums and have a function like this:

(defun enum-value (base value &key (min 0) (max most-positive-fixnum))
   (assert (or (keywordp value) (<= min value max)))
   (if (keywordp value)
     (foreign-enum-value 'enum value)
       (+ (foreign-enum-value 'enum base) value)))

and change gl:light to use it:

(defun light (light pname value)
   (let ((light-name (enum-value :light0 value :max 4096)))
      (%glLightfv light-name ...)))

There, problem solved. You can now call it like  
(gl:light :light7 ...) or (gl:light 7 ...)
and it should work. We don't even need to define new enums.


> Sorry, I meant CLX, not GLX :
> http://common-lisp.net/~crhodes/clx/gl.lisp
> and CL-SDL is a set of lisp bindings for SDL and OpenGL.
>
> The 2 libraries you linked both used GL_FOO style
> constants/defparameters though, so not sure how much it matters.

I didn't even look closely at them to be honest. It's just that I  
never see any juggling
of +constants+ in native Lisp code and think that it's a C-ism that I  
want to avoid.


> Might be, I'll have to see if I can think of any concrete tests and  
> try it...

Sure, it'd be nice to know for certain, but I can't imagine any  
situation where looking
up a few keywords at runtime would be a bottleneck in any shape, way  
or form
unless you construct such a case. You're supposed to minimize the  
number of
OpenGL calls anyway and I expect the cost of doing such a lookup is  
absolutely
dwarfed by the cost of doing the call itself and possibly introducing  
pipeline bubbles.


--
   Oliver Markovic