Ruby Binding for TGEA

Matthias Georgi — 2008-01-24T02:04:32+00:00

After finishing a working implementation of my binding for the Ruby language, I'm gonna try now a tighter support using gccxml. After reading the post of Prairie Games and their work on the Python binding I was inspired to use the same route for generating wrappers for C++ classes.

My current implementation asks the Torque Scripting Environment for all defined classes, methods and fields and generates wrappers as script files, which call my binding code to interface with the Torque Engine. This has the drawback, that arguments and return values are converted to strings and my binding has to figure out, how to convert back and forth using the intermediate string representation.

This works quite well and has some kind of type safety in contrast to the Torque Scripting Language. I was able to convert all torque scripts to ruby scripts and the syntax is very nice to work with. Especially the scripts for the world editor got a lot clearer by using Ruby. A simple example will show you the advantages of using a full fledged scripting language. This is my implementation of the FileDialog GUI:

class FileDialogClass < GuiControl
  
  child_accessor :window, :okButton, :cancelButton, :dirTree, :textEdit, :fileList
  
  def_on(:add) do

    window.on(:close) do
      close
    end
    
    okButton.on(:action) do |sender|
      @callback.call selectedFile
      close
    end
    
    cancelButton.on(:action) do |sender|
      close
    end
  
    dirTree.on(:selectPath) do |sender, path|
      fileList.setPath(path, @filespec)
    end
  
    fileList.on(:select) do |sender, id, filename|
      textEdit.setText(filename)
    end
    
    textEdit.on(:return) do |sender|
      @callback.call(selectedFile)
      close
    end
  end
  
  def open(title = "Open File", button_text = "Open", filespec = "*.*", &proc)
    window.text = title
    okButton.text = button_text 
    @filespec = filespec
    @callback = proc
    Canvas.pushDialog(self, 99)    
    fileList.setPath(dirTree.getSelectedPath, @filespec)
  end
  
  def selectedPath=(file)
    dirTree.setSelectedPath file
  end
  
  def selectedPath
    dirTree.getSelectedPath
  end

  def selectedFile  
    "#{selectedPath}/#{textEdit.getValue}"
  end
  
  def close
    Canvas.popDialog(self)
  end
  
end

Essential was the implementation of the Event/Observer pattern, which simplifies the use of callbacks like onAdd. In Torque Script you are limited to one callback method for an event like onAdd. In my implementation you can attach more than one event listener to one instance or to the class itself. So you don't have to use namespaces, instead you attach the event listener to a particular instance, which should be done in the onAdd event handler, which gets called right after the creation of an object.

You may have noticed the child_accessor method. This one generates a accessor method for getting the child or descendant of a SimObject. This is cool, as you can avoid messing up the global namespace. You just use the internalName property of a child object and reach it via the accessor method.

So back to the GCCXML stuff. This is really exciting, as the xml format exposes the internal structure of a c++ program. I'm currently working on a small library, which parses the xml and makes the program structure accessible to the ruby world.

A simple Rakefile (like Make in Ruby) will transform the C++ classes to their xml representation and automatically generate wrapper code, which can be compiled by good old Visual Studio. This route allows a tight ruby binding avoiding the intermediate string representation. Furthermore all desired elements of the engine may be exposed to scripting and the burden of writing repetitive wrapper code is avoided.

If anyone is interested in ruby development, just let me know. I have invested a lot of time into this stuff (about 2 years) and like to share my experiences.

Blog for Matthias Georgi at GarageGames.com

Ruby Binding for TGEA