On Wed, Oct 16, 2013 at 8:58 AM, Chris Bagley <chris.bagley@gmail.com> wrote:
> Cheers, good to know. OK going back and reading the code again, this all
> seems to boil down to the fact that some implementations of opengl are
> missing functions

It is mainly intended for OpenGL extensions, but Windows in particular
only supports gl 1.1 or 1.4 or so in the system libraries, so
everything beyond that has to be loaded the same way. Other systems
might be able to link more functions directly, but I'm not sure it
would be worth the effort to try to figure out which ones,
particularly since it might depend on drivers or hardware so needs to
be checked at runtime anyway.

> Does the resulting lisp program take a performance hit from having such a
> late compile?

I think the runtime compilation was intended to improve performance,
by compiling a specific function containing the function pointer
directly rather than precompiling a function that would have to look
it up somewhere for every call. That way the first call is a bit
expensive, but every call after that can be as fast as possible. No
idea how much difference it actually makes, or if it depends on lisp
implementation or platform though.

> It's a heck of an interesting problem, I hadn't really thought about how
> cl-opengl handled versions before. It's a pretty cool solution! Are there
> any features around this area that that need implementing or improvements to
> code that are needed? My main part time project totally relies on cl-opengl
> so it would be nice to give a little back!

Can't think of anything in that specific area that needs work, but
there is lots of room for improvement in the "high-level api" (the GL:
package) part of cl-opengl, particularly with more modern style of
OpenGL programming (shaders, vbos, etc).