<div dir="ltr">@bart:sorry if you receive this twice. I didn’t reply-all in gmail.<br>@all: Just resurrecting this question briefly as it has been playing on my mind.<br>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?<br>
If the answer is "go read them and find out" that is fine!<div class=""><div id=":1fe" class="" tabindex="0"><img class="" src="https://mail.google.com/mail/u/0/images/cleardot.gif"><br></div></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On 16 October 2013 18:44, Bart Botta <span dir="ltr"><<a href="mailto:00003b@gmail.com" target="_blank">00003b@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Wed, Oct 16, 2013 at 8:58 AM, Chris Bagley <<a href="mailto:chris.bagley@gmail.com">chris.bagley@gmail.com</a>> wrote:<br>
> Cheers, good to know. OK going back and reading the code again, this all<br>
> seems to boil down to the fact that some implementations of opengl are<br>
> missing functions<br>
<br>
</div>It is mainly intended for OpenGL extensions, but Windows in particular<br>
only supports gl 1.1 or 1.4 or so in the system libraries, so<br>
everything beyond that has to be loaded the same way. Other systems<br>
might be able to link more functions directly, but I'm not sure it<br>
would be worth the effort to try to figure out which ones,<br>
particularly since it might depend on drivers or hardware so needs to<br>
be checked at runtime anyway.<br>
<div class="im"><br>
> Does the resulting lisp program take a performance hit from having such a<br>
> late compile?<br>
<br>
</div>I think the runtime compilation was intended to improve performance,<br>
by compiling a specific function containing the function pointer<br>
directly rather than precompiling a function that would have to look<br>
it up somewhere for every call. That way the first call is a bit<br>
expensive, but every call after that can be as fast as possible. No<br>
idea how much difference it actually makes, or if it depends on lisp<br>
implementation or platform though.<br>
<div class="im"><br>
> It's a heck of an interesting problem, I hadn't really thought about how<br>
> cl-opengl handled versions before. It's a pretty cool solution! Are there<br>
> any features around this area that that need implementing or improvements to<br>
> code that are needed? My main part time project totally relies on cl-opengl<br>
> so it would be nice to give a little back!<br>
<br>
</div>Can't think of anything in that specific area that needs work, but<br>
there is lots of room for improvement in the "high-level api" (the GL:<br>
package) part of cl-opengl, particularly with more modern style of<br>
OpenGL programming (shaders, vbos, etc).<br>
</blockquote></div><br></div>