I’m going to have to wait until after we ship TR before I do any of the real work that I want to get done on RubyCube.

The sources in the distribution and on trunk can be built for Mac OS X for anyone who would like to experiment on that platform. Window start up time on my dual G5 is a bit slow for my tastes and I haven’t gotten in to optimize it yet.

I would like to thank basaah for his great suggestions and feedback on the 0.1.1 release.

I feel the code structure is straining a bit now that I’m starting to add in new objects.  It’s not terribly hard to add new functionality but the code base is definitely much larger than it was when I first threw this together as a proof of concept.

I’m going to do a dot release to document sprites and flush out the functionality. I’d love to get more feedback from anyone using RubyCube as to what you would like to see to make it more useful.

Since documentation is not yet ready for sprites the best way to see the API is in the new test/testsprite.rb driver.

• Download available here
• Updated docs available here

First problem I ran into was:

objc: failed objc_getClass(NSObject) for GLUTApplication->isa->isa objc: please link appropriate classes in your program Trace/BPT trap

This was pretty easily fixed by making sure to pass ‘-framework Foundation’ to the linker.

The next issue I’ve run into and I don’t have a good solution for so far is the GLUT startup performance on OS X. According to Sampler most of the time spent is in glutInit. When I drill down into glutInit I see that it is spending all it’s time in HIDUpdateDeviceList which it calls once during __glutGetNumberOfMouseButtons and again in __glutLoadPrefs. This descends down into a long chain of methods that appear to build an internal dictionary of devices (connected HID devices?). It appears this process is painfully slow, at least on my sample configuration.

I want the graphics window to pop up immediately (if at all possible) and so I’m going to have to spend more time figuring out the internals of what is really going on here. I’m sure it’s possible to speed it up but at what cost of my personal time? I’m not yet ready to write a specific windowing layer for the Mac.

RubyCube 0.1.1

I’m in the process of getting a new ruby forge project setup to host the project files, mirror the source depot and manage bugs.

I’m very happy with the overall quality of this initial release.

Incidentally, I also uploaded a copy of my async IO extension to ruby forge.

It takes some serious hardware to fight dragons, don’t go into a dragon fight without taking at least some of the following:

GlowCode, gprof, ElectricFence, LOP/F1 Profiler, BoundsChecker, ValGrind, dbghelp.lib, VLD

I put GlowCode at the front of the list intentionally. I just downloaded it but this thing is the excalibur of dragon slaying tools.

GlowCode is a great developer tool, it might look a little crufty but all the little interface issues are thought through and the thing is just fast and does everything you want right how you want it. I quickly found a number of hot spots in the game and immediately went to take a nap (no sense fighting a dragon while tired right?)

Out of curiosity I profiled the RubyCube stress test and timefree() was using about 50% of the total time, this is the internal ruby hook that returns a Time object to the heap. Of the other time 70% was spent in gshape_render() which is the function that renders a single shape. So again, this especially outlines the need to use an alternative timing mechanism in RubyCube. Exclusive time gives a good indication of what routines are doing the most actual work but often times looking at average or total Exclusive+Inclusive time can give you a good idea of where you might find some low hanging fruit.

All of the other tests are running well. One more documentation pass and I’ll be ready to do a windows release. I want to follow that closely with the mac release. To get things running on the mac should be as simple as:

1. Replace Win32 threads with pthreads (nothing fancy, just conditional compilation)
2. Ditto for the critical sections migrating to pthread mutexes.
3. Some cross platform glue sniffing in extconf.rb will be needed as well.

Having the test cases has been instrumental in making any progress. I keep the build stable between work sessions and focus all my work around achieving results in a test case. A lot of bugs and usability issues have been fixed already using this method. I added a couple big handfuls of useful functionality as a result.

As an example two new global methods ‘pause’ and ‘resume’ were added to allow me to control the animation test more explicitly. This is actually a really simple feature that is fun to play with.

Also as a result of this type of work I converted to using array tuples for vector arguments. This has made the ruby code more readable and allows an easier transition from 2D to 3D.

Timers are another big example, without the stress test I never would have seen the timer GC thrashing and decided to implement a timer event.

• Finished the stress test
• Finished first pass of documentation (rubydoc)
• More test cases for basic functionality
• Perspective transform is working

• Object destruction had to be optimized a bit. This is a bit tricky due to multithreading issues. Basically once the ruby script calls the registered free callback the object is marked for cleanup. The graphics/update thread handles reclaiming the actual memory in the main loop.
• I couldn’t find an effecient way to do game timers in ruby. This code looks nice but creates too many Time objects:

stopTime = Time.now() + 60
while(Time.now() < stopTime) do
  puts "thinking"
end

timerId = RubyCube.set_timer(10, -1) # interval 10 seconds, repeats forever
loop do
  event = []
  while(RubyCube.read_event(event)) do
    if(event[0] == RubyCube::TIMER && event[1] == timerId) then
      puts "hit timer"
    end
  end
end

• I cut the number of animation types supported and am still working on a test that exercises all of them.

• Animation tests
• Timer tests

• Proper lighting support. This really limits the usefulness of perspective mode.
• Physics support. The APIs are there but not tested or supported for now.

1. Lighting support
2. Texture/Material support
3. Physics support
4. Any user suggestions

It’s a simple idea but it can produce some very nice patterns.

Here’s life out of control, if you muck with the death condition:

Here’s a stable pattern produced by the block and blinker in the sample:

The code will be part of the samples but if you want to take a look I’ve uploaded it. Any comments are welcome, I know that I’m not the best Ruby coder out there.

For some reason the garbage collector still kicks in and starts reclaiming the shapes even if I keep references to them in the base script. Stress related crashes to look into now.

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

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

• Bug in non-supression of logging during test compile stage (using $debug rather than $DEBUG)
• Logging was too minimal overall, it was not clear in mkrf what settings and source it was trying to compile without getting into the code.
• Mkrf uses the wrong rbconfig settings for test compiles, the settings are not compatible on platforms other than the one it was written on. It should take a note from mkmf in this regard and use Config['TRY_COMPILE'] instead of Config['CC']
• It was not possible without a hack to modify the library search path of @availability before test compiles were invoked. This is troublesome when you have cascading library dependencies.
• Using rake is neat idea but it adds a seperate dependency to a project (albiet one that is easily resolved by rubyists who know how to install rake). I would like my extension to have as low a barrier to entry as posible to encourage non-ruby programmers to try it.
• All standard extensions use mkmf and so you know that if they could compile ruby on their systems (which many systems can by this point), they can compile your extension.

technorati tags:ruby, rubycube