On Thu, May 3, 2012 at 8:28 AM, Mike Pall
<mikelu-1205@mike.de> wrote:
Alex wrote:
> The FFI headers I'm using were parsed from GLEW on my Windows x64, which is
> probably why they are there. I'll try re-processing the headers tomorrow in
> Linux and see if it clears up.
Umm, you may get into trouble if you process headers on 64 bit and
use them on 32 bit, anyway. That is, unless you're very, very
careful to abstract out all the word size dependencies with
ptrdiff_t, size_t, intptr_t, uintptr_t etc. And then there are
some libraries which have incompatible APIs on each platform,
hidden behind a mess of macros ...
Yea, hence why I was going to reprocess them.
> gllib = setmetatable({}, {__index=function(self,k) return lookup[k] and
> glew[lookup[k]] or gl[k]})
>
> I'm not quite sure how else to redirect them short of using the GLEW
> internal functions everywhere.
The first thing that comes to mind is to cache the lookup result
in the table.
But the real question is why do you use GLEW at all? This may be
convenient for C/C++, but the LuaJIT FFI offers lots more magic to
automate all of that. There are several FFI GL bindings out there,
and someone must have solved that problem nicely by now.
Mostly because it was an easy(er) way to use OpenGL extensions, namely shaders, which I haven't seen in existing solutions. Though I guess with all the trouble this is giving me it may be worth it to start using the glext.h file...
