Jacob Repp

Since I’ve not had a lot of time for home-hack projects lately I’ve been focusing on getting RubyCube ready for release. It’s a small, well contained project, it’s easy to make good progress with only 30 minutes of invested time.

RubyCube is a ruby extension that gives a high level ruby API on top of GLUT and ODE currently. It abstracts away some stuff that doesn’t really belong in a graphics scripting environment but you tend to see people include anyways (like the render/update loop). I used it back in March of ‘06 to write a game with my friend John in a matter of hours.

When I started I decided that I didn’t want the render loop to be bound to the performance of the ruby VM since it’s performance is pretty crap. Craps! score doesn’t really account for object lifetime management overhead which Ruby may have some issues with as well. Regardless of that I really like the language and I think it could make a good prototyping environment for game programming.

Most people when they create a language wrapper for something like OpenGL or DirectX write a direct 1-to-1 mapping (luasdl, rubysdl, rubygl, etc). This is probably due to simplicity of implementation and maybe lack of imagination . It may have something to do with not really understanding the problem domain very well, which is a huge barrier to successful software design in general.

So the way that I approached the problem is to create a seperate thread in the extension and use queues to communicate between the script interface and the extension. The render and object update loop is handled in C. This has a lot of benefits but is more complex to code. Overall, I have been very pleased with this design. Currently the interface is very simple, it’s intended as a prototyping environment. It’s not the kind of thing you would build a whole game on at this point. I’m going to try the approach of release early, release often and see how that goes. I was planning on including texture support in the first release but I think I’m just going to finish the docs and tests and release it as is.

It currently only supports vector based graphics, no lighting and only a few simple types of animations. Oh and it doesn’t yet compile on my Mac.

One nice benefit of using a background thread is that you watch the render window while you’re in irb.

irb -r rubycube

irb> RubyCube.startup(”My test application”, 800, 600) # create the window and thread irb> myshape = Shape.circle(100, 200, 50) # create a circle at 100,200 with radius 50 irb> myshape.move_to(300, 300, 2) # move to <300,300> in 2 seconds irb> myshape.color(1, 0, 0)

You can also create custom shapes that are lists of verts, normals, colors. You can create thousands of shapes and have them animate very easily without burdening the ruby interpreter.

For the first release I’m shooting for the following:

• All core methods documented
• Test cases for all animation types
• Test cases for ODE physics on shapes simulation
• Finish stress test
• Perspective transform mode working

In rough order of importance after releasing the basic framework will be:

• Mac OSX support
• Texture/Material support
• Sound support
• Shader support
• Implement changes from user feedback (if any)

Related posts:

• RubyCube progress
• RubyCube 0.2.1 released to RubyForge
• RubyCube 0.1.1 Released
• mkmf versus mkrf round 1
• RubyCube stress test

Trackback URI | Comments RSS