@bart:sorry if you receive this twice. I didn’t reply-all in gmail. @all: Just resurrecting this question briefly as it has been playing on my mind. We use runtime compiling to create our wrappers in case functionality is not present. That is great, but how do more static languages that don’t have this kind of control handle multiple versions of opengl? If the answer is "go read them and find out" that is fine!
On 16 October 2013 18:44, Bart Botta 00003b@gmail.com wrote:
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).