[ruby-opengl-devel] Project status

Al Hoang hoanga at alum.rpi.edu
Mon Feb 19 22:55:13 EST 2007

Hi Jan,

    Sorry for the extremely slow response on this message.  I've been
meaning to respond to this message for awhile now but wanted to make sure
I fully digest what you said :-)

On Wed, Feb 14, 2007 at 02:52:16AM +0100, Jan Dvorak wrote:
> 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 

    Better support for more recent releases of OpenGL sounds great.  I
had a much lower goal of just making sure that 1.0, 1.1 support was solid
and seeing what to do from there but you seem to have a much clearer
idea on how to shoot for more recent support without busting what is there.
I'm all for this.

> 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 

    Interesting.   This is something I didn't consider at all but something
definitely that makes sense.   Well putting in this support now is good
although at the current moment, ruby-opengl doesn't do much to build
anything on win32 at the moment.   I'd really like to have this fixed but
mkrf itself doesn't seem to support building on win32 except perhaps
via cygwin so most likely changes to mkrf will have to be made to support

> 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:

    This sounds perfectly fine.  In fact it's probably already in the svn
trunk since I committed your patch a couple of hours ago.

> version after version - there is not that much functions), the real problem 
> is testing. Most of OpenGL functions cannot be tested automatically,  the 

    I was afraid of this.  I have been agonizing trying to think of a way
to automate testing OpenGL but it just doesn't seem possible.   The best
that could be done is test whether calling to a certain OpenGL function
will return an error or not but even that sounds iffy.

> 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". 

    This sounds fine.  I actually think what would be handy is to have
a small thumbnail picture that should resemble or be a smaller rendition
of what the user should expect to see.  If the files aren't that large
we can stuff them in the test directory under the same name as the test
itself for easier identification.  

> 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.

    This might not be a bad idea at all or perhaps we can try to take
advantage of Ruby's DL library to bind to the GLU library dynamically.

> 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.

    Perhaps, GLUT could just stay the way it is in ruby-opengl as I'd
imagine people would move onto some other windowing toolkit if they wanted
more features than what the current basic GLUT interface can provide.


More information about the ruby-opengl-devel mailing list