[ruby-opengl-devel] Project status

Jan Dvorak jan.dvorak at kraxnet.cz
Tue Feb 13 20:52:16 EST 2007

On Tuesday 13 February 2007 03:20, Al Hoang wrote:
>     Actually, that needs to be updated.  The development status is no
> longer stalled due to mkrf as a new release of mkrf fixes those problems.
> The next step was for me to kick off a release as is but I needed to clean
> up the Rakefiles so that it will cleanly generate a gem.  Once the build
> system gets clean, I think development can really start plodding forward
> again.
Thats good to hear.

>     I'd happily accept patches for anything you're thinking of
> implementing. What were your ideas?
I was thinking about best way to continue development to get full OpenGL 2.1 
support, along with most extensions (although considering their number, this 
is more of wishfull thinking). Currently in the bindings there is good 
support for 1.0,1.1 and some functions from 1.2 version; the system is 
static, what functions are included in ruby bindings depends on what GL 
headers are installed on the system at compile-time - which isn't good, as on 
90% or so systems the headers version doesn't match what is actually 
supported in drivers. (This is most prevalent on windows, where there are 
only GL 1.1 or 1.2 headers included in most compilers/IDEs). And even if they 
match, it still means recompiling the bindings each time new graphics drivers 
are installed should you want to use the additional capabilities.  My 
suggestion is to dynamically load functions of versions 1.2+ (taking version 
1.1 as lowest common denominator, as it is available on windows 98).  The way 
wrapper functions are written won't change much:

void (*glFunction)(int,int) = NULL; // define function pointer prototype
static VALUE gl_Function(....
  if (glFunction==NULL) { // can be macroized 
     glFunction = our_dyn_load_func("glFunction"); 
    // which will call glXGetProcAddress on unix,
    // wglGetProcAddress on windows or
    // dlsym/dyndl functions on mac
    // if fail, raises "Function not available" or "OPenGL context not set"
  rest of function as usual
The function address will get loaded on first use of the function, so there is 
no initliazation overhead for scripts which doesn't use any it. Once loaded, 
only one "if" is executed on each function call, so this should also not be 
problem performance-wise.

There should also be ruby function mapped directly to our_dyn_load_func, which 
will allow the user to check if specific function is available in runtime.

Of course, the implementation is the easy part (it can be built slowly, 
version after version - there is not that much functions), the real problem 
is testing. Most of OpenGL functions cannot be tested automatically,  the 
tests needs to be interactive. I guess we don't need to write individual test 
for each function, we can test multiple functions of the same subset at 
once - i was thinking about screen displaying some stuff and describing text 
like "you should see three rows of red, green and blue quads, press Y/N". 
(Because OpenGL doesn't really change, and the wrapper functions are 
standalone, not dependent on others, these tests should fortunatelly be 
executed by developer only if someone changes the code of function in 

As for GLU, it doesn't have means for dynamic function loading as it usually 
isn't part of the drivers. Latest revision is 1.3, with previous version 1.2 
being distributed along OpenGL 1.1 (which as i wrote can be taken for 
granted) so it is only small number of functions which availability would 
depend on compile-time. The good thing is, all of GLU functions are 
higher-level stuff, using only other GL functions, meaning that if really 
needed, they can be (re)implemented even in Ruby itself without need for C 
code or wrapper.

As for Glut, the situation is the mostly the same as with GLU. It's more 
complicated as there are both higher level and core functions interfacing 
with the GUI API (glX/wgl etc.)  which needs to be implemented. As the 
original Glut is not developed anymore, there are also many spinoffs 
(freeglut..), with different functions and extensions. Fortunatelly, the core 
functions didn't really change from 1994 or such (so we can safely assume all 
are available at compile time), and the rest is also mostly higher-level 
functions as with GLU.

Now, i didn't really read the list archives, so if any of this was already 
discussed please point me to the relevant threads. Any comments are of course 

Regardless of any of this, i already started implementing the few 1.0 and 1.1 
functions that are currently missing from the bindings, and i'll put the code 
on my ftp when i'll check everything is working ok (i can also provide 
patches if needed).


More information about the ruby-opengl-devel mailing list