[ruby-opengl-devel] about gl_untyped.i
peter.mclain at gmail.com
Tue Aug 29 14:22:58 EDT 2006
> I'm wondering why is there a gl_untyped.i :
> I mean, I know what's its purpose, but why is it done in C and why is
> it done in a .i ?
I think the answer to this question and the one below is just the
history of how I've been working on the project and the fact that the
project has just started...
I started working on this project because I needed a ruby extension
to a version of OpenGL newer than 1.2. So, my first step was just to
try and get some very simple scripts working (the ones in the test
dir). I decided the size of OpenGL (and GLU and Glut) mandated some
sort of automation, at least to generate the initial .c files. I
tried to let SWIG do it all, but there were some issues that needed
fixing. Amongst those issues was the test script included the untyped
ruby calls. So, I just cut-n-pasted from Yoshi's code into glut.i,
tweaked and it started working. I continued to port a few more
scripts with the intent of uncovering other areas where the swig
generated code needed help. The other thing I've spending time on
(and one of the main purposes of my involvement in the project) is
learning rake, and swig, and ruby extensions, and rdoc, and all the
other ruby-ways of doing things.
I think you raise interesting questions, and the project is probably
far enough along to begin to answer them.
> The fact it's done in a .i is maybe so we can use the %init SWIG
> clause... and keep the number of files low. I thought that kind of
> thing would be in its own .c file.
I think that *if* we think untyped support should be done in the C
wrapper, then we should look at how to balance what goes in the .i vs
what goes in a .c support file. But I'm liking your ideas below...
> Another approach, which I like, would be to keep the .bundle/.so
> restricted to call the original libs (i.e. without the extra 'untyped'
> functions) and put those 'extra' in a separate .rb file.
> Briefly : minimal .bundle/.so wrapper modules and cool ruby stuff in .rb.
> So we can either :
> require 'opengl' (for other toolkit) or
> require 'glut' (which requires itself opengl) or
> require 'super_rubyish_opengl'
I think I like this approach as it simplifies the task of getting
the basic opengl port up and running (we can declare victory for
super_rubyis_opengl hits the streets) and I don't have any good reason
why the untyped support is written in C rather than ruby (perhaps
performance??)...Yoshi did it that way and at this point in the
project all I've done is unthinkingly copied it.
> what's the reason to call the gl*d versions, not the gl*f versions ?
Again, that's just the way Yoshi happened to write the code I
cut-n-pasted. I think he just sais a double is at least as good as a
float, so just do it that way. I think that for small datasets it is
safe (won't loose precision) and if you really want the efficiency of
not passing twice the bytes down to the card, then you can always call
the appropriately typed version.
peter.mclain at gmail.com
More information about the ruby-opengl-devel