I’ve tinkered a bit with Yoshi’s original ruby-opengl. My changes are
available here:
http://www.simisen.com/cgi-bin/jmg/ruby-opengl.rb
The point of the changes started out mostly as an interest in getting
some tutorial content together, but soon spiraled out of control
resulting in me putting that little site up along with the modified
ruby-opengl files (plus some docs).
Anyhow, let me know if you think there’s any interest in this.
Thanks,
—John
On 7/7/06, John G. [email protected] wrote:
[snip], but soon spiraled out of control
resulting in me putting that little site up along with the modified
ruby-opengl files (plus some docs). [snip]
Whoops. Forgot the smiley.
It’s the good kind of spiraling. 
—John
From: “John G.” [email protected]
I’ve tinkered a bit with Yoshi’s original ruby-opengl. My changes are
available here:
http://www.simisen.com/cgi-bin/jmg/ruby-opengl.rbThe point of the changes started out mostly as an interest in getting
some tutorial content together, but soon spiraled out of control
resulting in me putting that little site up along with the modified
ruby-opengl files (plus some docs).
Hi,
I think it’s great that ruby-opengl has an active maintainer
now, and your website looks very nice.
If you’re interested in linking to additional related libraries,
Ilmari H. and I have FTGL bindings for Ruby here:
http://rubyforge.org/projects/ruby-ftgl/
(True-type fonts in OpenGL).
One thing, from your home page:
I decided I really didn't like the way the GL calls looked
(they used to always be prefixed with the module name
(unless you did an include) and they started with a capital
letter -- which is against the usual Ruby convention).
So that's been changed ...
You don’t mention whether you’ve left the original API
intact for backward compatibility. It sounds like you’re
saying you went ahead and broke compatibility with all the
ruby OpenGL code that we’ve all written in the past half
decade!
I can’t begin to describe how ill-advised I think it would
be to break compatibility with 100% of the existing codebase
just for relatively minor aesthetic reasons.
Regards,
Bill
Did you look at Yoshi’s install? I was not able to install 0.32g on
tiger with the 1.8.4 ruby. I was able to install it with 1.8.2 ruby,
moving the bundles to a directory 1.8.4 could see. Unless people can
install…
I can see why you would want to do away with GL and GLUT in front
of the function, less typing, but for a beginner, they were very
useful. I should still be able to put them in front, no?
a) I found the GL and GLUT in front of the opengl function very helpful
just to remember what library the function came from
b) Swapping GL for a new class, I was able to redirect the output which
I found very useful:
as an opengl beginner, I found it difficult to figure out what the
opengl code was that I was outputing, given that I had recursive calls
through trees… (for the limb of a person for example) replacing GL by
a new class constant gave me a wonderful tool to redirect the code to a
text file without changing any of the code.
RealGL = GL
class LoggingGL
class << self
def method_missing(meth, *args)
puts “#{meth}(#{args.join(', ')})”
RealGL.send(meth, *args)
end
def const_missing(const)
RealGL.const_get(const)
end
end
end
GL = LoggingGL
“Your Ruby GL code should look a whole lot like your C code”
I don’t agree with that idea at all. I spent a lot of time working on
robot.rb so it would take advantage of the
OOP aspect of ruby, and as a consequence, my ruby openGL does not look
much like the C code I think.
If I am going to code in ruby the way I would in C I don’t really see
the point in using Ruby. In ruby, I am trying to code the ruby way.
Thank you for giving an example of the use of lambda. It took me a
while to figure out how to use that feature - with help from this list
– as Yoshi’s examples are straight C translation which use a fx.
reshape = lambda do |w, h|
glViewport( … )
glMatrixMode( GL_PROJECTION )
# etc.
glMatrixMode( GL_MODELVIEW )
glLoadIdentity
end
glutReshapeFunc( reshape )
On 7/7/06, anne001 [email protected] wrote:
- Did you look at Yoshi’s install?
Well, I had a look through extconf.rb if that’s what you mean.
I was not able to install 0.32g on
tiger with the 1.8.4 ruby. I was able to install it with 1.8.2 ruby,
moving the bundles to a directory 1.8.4 could see.
Ilmari H. alerted me to a fix for Mac OS X. I’ll try to apply
that soon.
Unless people can install…
- I can see why you would want to do away with GL and GLUT in front
of the function, less typing,
Well, it’s not really much less typing.
GL_FOO_BAR instead of GL::FOO_BAR
glFooBar instead of GL::FooBar
The real reason for the name changes is to make the calls look more
like they are in C.
but for a beginner, they were very
useful. I should still be able to put them in front, no?
Yeah, if you use the version I just provided, you can still do that.
But it may not stay that way. Though, if you prefix your calls,
they’ll have to look like GL::glFooBar instead of GL::FooBar.
RealGL = GL
end
endGL = LoggingGL
I’ll have to think about that. Thanks for the link.
- “Your Ruby GL code should look a whole lot like your C code”
I don’t agree with that idea at all. I spent a lot of time working on
robot.rb so it would take advantage of the
OOP aspect of ruby, and as a consequence, my ruby openGL does not look
much like the C code I think.
If I am going to code in ruby the way I would in C I don’t really see
the point in using Ruby. In ruby, I am trying to code the ruby way.
Maybe I wasn’t being clear there. You can still do all sorts of OO
tricks in your Ruby code. I meant to say, “Your Ruby calls to GL code
should look a whole lot like they do in C.”
BTW, lots of folks write OO code in C, or so I hear.
- Thank you for giving an example of the use of lambda.
You’re welcome, but I must admit that I don’t yet see why it just
doesn’t use a top-level method instead of that lambda. I just copied
what I saw in the samples. I’ll have to ask about it on the list
sometime.
end
glutReshapeFunc( reshape )
- I would be happy to pass you a copy of the robot.rb version I worked
on. I would love for someone who knows ruby
Well, I’m still a novice at Ruby (as of this afternoon).
to improve on it so people
have a real ruby way opengl example, instead of souped up C opengl
example to start with.
Haven’t yet had a chance to look at robot.rb. I’m only done with the
'a’s so far! Thanks for the offer.
—John
It would be great to have people to keep opengl going, people who
understand install issues, and could bring some vitality to examples,
discussions etc…
Just with install issues, having an opengl maintainer willing to figure
out how to install on all systems would be great. But then if you could
do that, you could help with yoshi’s package as well as with your
modification.
I wonder if there is a softer way of keeping yoshi’s code as the
mainstay, but have your version run as well. As Bill is suggesting, to
add to the code rather than alter it in an uncompatible way.
Down the road, people could choose.
On 7/7/06, Bill K. [email protected] wrote:
Hi,
I think it’s great that ruby-opengl has an active maintainer
now,
Hm.
and your website looks very nice.
Thanks.
If you’re interested in linking to additional related libraries,
Ilmari H. and I have FTGL bindings for Ruby here:
http://rubyforge.org/projects/ruby-ftgl/
(True-type fonts in OpenGL).
Will take a look. Thanks.
One thing, from your home page:
I decided I really didn't like the way the GL calls looked (they used to always be prefixed with the module name (unless you did an include) and they started with a capital letter -- which is against the usual Ruby convention). So that's been changed ...You don’t mention whether you’ve left the original API
intact for backward compatibility.
It’s not intact in my version.
It sounds like you’re
saying you went ahead and broke compatibility with all the
ruby OpenGL code that we’ve all written in the past half
decade!
Yes. Perhaps I need to rename it then.
I’m not trying to be the new maintainer of ruby-opengl per se. I just
wanted to use more normal lookin gl calls in my little hobby-type gl
apps, and so modified ruby-opengl to make it so.
I can’t begin to describe how ill-advised I think it would
be to break compatibility with 100% of the existing codebase
just for relatively minor aesthetic reasons.
Thanks for the note Bill. Looks like I made an error, and should
probably rename the project to something else.
(new “ruby-opengl” page temporarily taken down)
—John
From: “John G.” [email protected]
I’m not trying to be the new maintainer of ruby-opengl per se.
Rats. Because I really liked the web site.
I just
wanted to use more normal lookin gl calls in my little hobby-type gl
apps, and so modified ruby-opengl to make it so.
Incidentally, I’d wager the reason the C-style GL calls all
use function name prefixes, is because that’s standard practice
in ‘C’, since there’s no namespace or module-like mechanism.
I doubt whether we’d prefix all our functions like that in
‘C’ if we had an alternative.
That’s why Yoshi’s placing the GL calls into modules never
bothered me, for the ruby bindings. It seemed a reasonable
fit for a language that does have namespaces. (Why preserve
a ‘C’ language convention that exists only to work around
that language’s lack of namespaces?)
In any case - welcome to Ruby!
Regards,
Bill
On 7/7/06, Bill K. [email protected] wrote:
From: “John G.” [email protected]
I’m not trying to be the new maintainer of ruby-opengl per se.
Rats. Because I really liked the web site.
Well then, I’ll have to see what I can do:
http://www.simisen.com/cgi-bin/jmg/ruby-opengl.rb
I reverted my changes to the method names, so it’s back to being
“ruby-opengl”. Please take a 2nd look.
Also, if there’s any Mac OS X Ruby OpenGL users out there, note that
there seems to be one last issue with getting this to work correctly
on OS X. I’ve incorporated some changes by James A. that Ilmari
pointed out to me, but there’s seems to be a last hurdle on OS X to
get them working. It may build and run with no changes but with a
current version of Ruby on OS X. Dunno. But there’s issues with it
working with whatever older version of Ruby Apple provides.
—John
From: “John G.” [email protected]
I reverted my changes to the method names, so it’s back to being
“ruby-opengl”. Please take a 2nd look.
Awesome! Much appreciated… It’s a weight off my mind to
not have to worry about the API changing.
BTW, here’s one possible way to define the prefixed methods
and constants, if you prefer to work with them that way.
You could require a file that does something like the
following:
require 'opengl'
class Object
(GL.methods - Object.methods).each do |m|
define_method("gl#{m}") {|*args| GL.send(m, *args)}
end
(GLU.methods - Object.methods).each do |m|
define_method("glu#{m}") {|*args| GLU.send(m, *args)}
end
end
GL.constants.each do |c|
Object.const_set("GL_#{c}", GL.const_get(c))
end
GLU.constants.each do |c|
Object.const_set("GLU_#{c}", GLU.const_get(c))
end
This should import the GL and GLU methods and constants
into the global namespace, using their traditional
prefixed nomenclature.
(Note: Only lightly tested… but I think it works…
Regards,
Bill
On 7/7/06, Bill K. [email protected] wrote:
From: “John G.” [email protected]
I’m not trying to be the new maintainer of ruby-opengl per se.
Rats. Because I really liked the web site.
Hey, thanks. I don’t think it’s gone for good, I just don’t want to
false advertise. Thanks for pointing out the problem.
I just
wanted to use more normal lookin gl calls in my little hobby-type gl
apps, and so modified ruby-opengl to make it so.Incidentally, I’d wager the reason the C-style GL calls all
use function name prefixes, is because that’s standard practice
in ‘C’, since there’s no namespace or module-like mechanism.I doubt whether we’d prefix all our functions like that in
‘C’ if we had an alternative.
Then what would you think of GL::foo_bar instead of glFooBar? I really
don’t like ruby-opengl’s current GL::FooBar, since that looks like a
constant to me in Ruby.
The trouble with that though (using GL::foo_bar), is, if you
include the GL, GLU, and GLUT modules, you might then have possible
name collision issues (if you take away the prefix, the GL function
names start looking pretty common).
That’s why Yoshi’s placing the GL calls into modules never
bothered me, for the ruby bindings. It seemed a reasonable
fit for a language that does have namespaces. (Why preserve
a ‘C’ language convention that exists only to work around
that language’s lack of namespaces?)
Well, the reasons that make sense to me are:
Lots of OpenGL C code uses those names, so it would likely make
“porting” a lot easier (not that you’d often port working C code to
Ruby, but “porting” could mean just turning pseudocode into Ruby, for
example, or maybe C snippets you find on the 'Net). Probably much more
common would be to first write your GL code in Ruby, then, if
necessary for performance reasons, you might end up recoding it in C.
Using normal GL names would make this much simpler, I think.
Folks are already used to the glFooBar names, which are quite well
established.
It makes it easier for folks new to Ruby and/or GL to follow along
with the many tutorials on the 'Net (since they mostly all are for C
and use the customary gl names).
If I do preserve the namespaces, then I’m stuck with function names
in Ruby that start with a capital letter, which really don’t look
right for Ruby.
In any case - welcome to Ruby!
Thanks.
On 7/9/06, anne001 [email protected] wrote:
One Tiger trick
One of the tricks I found on the internet, which seemed to help me was
to make a GL directory in the opengl folder in which you are trying to
build opengl.
find the GL libraries the install is looking for on your computer and
copy them in that directory.
OS X seems a bit complicated when it comes to libraries. I think
there’s .dylib’s, .so’s, .bundle’s, some are in “frameworks”… If
someone knows of an extension module that builds on OS X, please let
me know so I can take a look at its extconf.rb.
One Tiger trick
One of the tricks I found on the internet, which seemed to help me was
to make a GL directory in the opengl folder in which you are trying to
build opengl.
find the GL libraries the install is looking for on your computer and
copy them in that directory.
On 7/9/06, Bill K. [email protected] wrote:
class Object
Object.const_set(“GL_#{c}”, GL.const_get(c))(Note: Only lightly tested… but I think it works…
It seems to work! Thanks! I just added it (Ilmari had also offered a
solution, which I appreciate very much, but I ended up using yours).
Have a look:
http://www.simisen.com/cgi-bin/jmg/ruby-opengl.rb
I’ve only tried it so far with samples/smooth.rb. It’s late and I
really have to get to bed.
Thank you again. This is really shaping up nicely, IMO. The current
release is labeled 0.34pre because I’d like to hear from someone
running Mac OS X 10.4 if it builds and runs there out-of-the-box. I’d
also like to “port” more of the samples over (I figure I’ll try to
provide at least a good number of samples written in both styles).
If anyone wants to help with that, be my guest.
Anne, you’re on 10.4 (“Tiger” I suppose – I don’t know the Apple
cat-names for them), right? Does this latest release work for you
without any tweaking?
Thanks,
—John
Hi,
On 7/9/06, Bill K. [email protected] wrote:
end
#define_method makes somewhat slower methods than alias_method.
If an app is making lots of GL calls, it might cause some slowdown.
I doubt it makes much change in real applications, but here’s a silly
micro-benchmark anyhow:
$ ruby bench_alias_define.rb
user system total real
Foo 0.200000 0.030000 0.230000 ( 0.224021)
FooAlias 0.190000 0.030000 0.220000 ( 0.222571)
FooDelegate 0.810000 0.100000 0.910000 ( 0.909526)
On 7/11/06, Ilmari H. [email protected] wrote:
(GLU.methods - Object.methods).each do |m|
$ ruby bench_alias_define.rb
user system total real
Foo 0.200000 0.030000 0.230000 ( 0.224021)
FooAlias 0.190000 0.030000 0.220000 ( 0.222571)
FooDelegate 0.810000 0.100000 0.910000 ( 0.909526)
I get about the same results on my system too. Nearly the same with
bmbm instead of bm too.
Thanks for your patience in helping me understand this Ilmari. The ri
docs on extend don’t cover it the way you’re using it, and I don’t
understand the brief explanation in the PickAxe v2 (bottom of p.385).
It looks to me like putting extend self inside a module turns all
its instance methods into module methods. All of them – ones you’ve
already defined, and the ones you’re going to define – aliases
included. I guess aliases are just like methods in this case (?).
Also, it seems that you can use strings in place of Symbols in the
args to alias_method and public. For some reason, that reminds me
of a symbolic reference (a la Perl).
Anyhow, I see I have more to learn here, and your stategy seems quite
a bit faster, so I’ll probably go ahead and switch to it unless anyone
can point out a reason not to. What do you think Bill?
Thanks. Me thinks me need coffee now.
—John
From: “John G.” [email protected]
Anyhow, I see I have more to learn here, and your stategy seems quite
a bit faster, so I’ll probably go ahead and switch to it unless anyone
can point out a reason not to. What do you think Bill?
I think I would have done it like Ilmari did it, had I
known how.
There were a few things I thought were sub-optimal about my
approach: Subtracting out Object.methods seemed cheesy (but I
didn’t know about the include_super=false boolean flag);
Dumping the methods directly into Object seemed cheesy (I
prefer the way Ilmari creates a new container module which
can be included); and of course the implied overhead for the
delegation (which I was aware of, but didn’t realize could
be so readily avoided with alias_method.)
Regards,
Bill
From: “Ilmari H.” [email protected]
FooDelegate 0.810000 0.100000 0.910000 ( 0.909526)
module FooAlias
include Foo
extend selfFoo.instance_methods(false).each{|mn|
alias_method “a_#{mn}”, mn
public “a_#{mn}”
}end
Sweet. I learned about three new tricks from that. 
Thanks,
Bill
I think you’re aware of this, but it seems to build and run fine on
OS-X 10.4. Here’s the compiler output though, if you’d like to see
the warnings:
gcc -fno-common -I. -I/System/Library/Frameworks/OpenGL.framework/
Now Making opengl extension module…
glu.c: In function ‘glu_UnProject’:
usr/lib/ruby/1.8/powerpc-darwin8.0 -I/usr/lib/ruby/1.8/powerpc-
darwin8.0 -I. -c ogl.c
gcc -fno-common -I. -I/System/Library/Frameworks/OpenGL.framework/
Headers -I/System/Library/Frameworks/GLUT.framework/Headers -I. -I/
usr/lib/ruby/1.8/powerpc-darwin8.0 -I/usr/lib/ruby/1.8/powerpc-
darwin8.0 -I. -c rbogl.c
cc -bundle -framework OpenGL -framework GLUT -framework
Foundation -L"/usr/lib" -L"/System/Library/Frameworks/
OpenGL.framework/Libraries/" -o opengl.bundle glu.o ogl.o rbogl.o -
lruby -lGLU -lGL -lruby
Thanks very much, I think I’ll be using this 
Cheers,
Benj
On 7/11/06, Bill K. [email protected] wrote:
From: “John G.” [email protected]
Anyhow, I see I have more to learn here, and your stategy seems quite
a bit faster, so I’ll probably go ahead and switch to it unless anyone
can point out a reason not to. What do you think Bill?I think I would have done it like Ilmari did it, had I
known how.
Cool. Updated:
http://www.simisen.com/cgi-bin/jmg/ruby-opengl.rb
Thanks again Ilmari.
—John
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs