RE: Proper OpenGL dynamic library

  • From: William Adams <william_a_adams@xxxxxxx>
  • To: <luajit@xxxxxxxxxxxxx>
  • Date: Sun, 15 Jul 2012 01:12:58 +0000

I took a slightly different approach to this problem. I wrote something here:
 My observation was that the hardest part about dealing with OpenGL/OpenCLis 
simply typing in all those function signatures. Once you have those, there are 
myriad ways to solve the general extensionproblem. I chose to just create a 
table with a meta __index function.  whenever the function is not found, it is 
looked up, then added to the table for future quick reference. I wanted to use 
this mechanism, because as soon as you deal with thegeneral OpenGL extensions, 
you'll want to deal with setting and getting uniform values on your shaders.  
Rather than inventinganother mechanism for that, I tried to utilize the same 
general technique,that is, allowing the __call to look things up, and use 
__newindex, __indexappropriately. That technique has worked fairly well for me, 
and the code is verycompact, and doesn't require any additional libraries to be 
compiled. The part that is platform specific is very small, and can be easily 
changed.I only did it for Windows. -- William

- Shaping clay is easier than digging it out of the ground.

 > Date: Wed, 11 Jul 2012 20:57:10 -0700
> From: malkia@xxxxxxxxx
> To: luajit@xxxxxxxxxxxxx
> Subject: Proper OpenGL dynamic library
>      Hi folks,
>      This post is not directly connected with LuaJIT, but if you are 
> using any of the OpenGL FFI bindings you might be interrested.
>      One little problem with OpenGL ffi bindings (not limited to luajit 
> only) is getting around missing OpenGL extensions, like glCreateShader 
> on Windows.
>      Although it's possible to get and call each extension by luajit/ffi 
> alone, it's a bit nuisance to have to do it in first place. And wrapping 
> "C" exported functions and "lua" wrappers under one dll "table" 
> (gl.Xxxx) might create some slowdowns (I've tried it long time ago, and 
> it was not pretty).
>      The C/C++ folks had it the easy way with GLEW/GLEE/GL3W and others, 
> but these are C/C++ pre-processor macro tricksters that are not straight 
> forward to port to luajit/ffi land.
>      So instead of going through all hurdles, there is a solution (and 
> multi-platform at that):
>      On Windows it would create regal32.dll that exports every glXxx 
> function, wglXxx and two RegalXxx ones. Instead of loading OPENGL32.DLL, 
> load REGAL32.DLL in it's place (gl = ffi.load("regal32")).
>      There is also iOS, Android, OSX and GLX (Linux) support, but not 
> sure what it achieves there.
>      The library can be compiled with optional logging, asserts/error 
> checking so it might be useful for other stuff too.
>      I hope I haven't disturbed the forum by posting something a bit 
> irrelevant, but thought it's somewhat related and might ease the pain 
> for people using OpenGL through the wondrous FFI.
>      Thanks,
>      Dimiter 'malkia' Stanev.
>      P.S. The default regal.sln for VS2010 targets MSVCR100.dll (/MD), 
> you can retarget static linking /MT - this way you don't have to 
> distribute VS2010 dll's around.
>      It's a bit big dll - 3mb (32-bit version), but switching from /O2 
> to /O1 and optimizing for size could make it down to 2mb.

Other related posts: