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).