bookmark_borderIntroducing libDTShape

When developing 3d games, the allure of using a pre-built game engine is all too great. The trouble is nowadays you really need a good content pipeline in order to take 3d objects from your modelling tool and render them in your game, which in the past has usually required someone on the development team to write an elaborate tool-specific exporter script or plugin.

Fortunately nowadays with solutions such as collada you can now pretty much skip the “write exporter” stage and move the logic to generate runtime model data into the engine itself. However you still need something to handle animation and skinning. There are a few solutions out there, but they either contain too much baggage or the licensing isn’t so great.

So I decided to try making something myself. My requirements were as follows:

  • Written in standard C++
  • Engine-Agnostic
  • Renderer-Agnostic
  • Cross-Platform
  • Proven codebase

Most importantly I wanted to base my solution off of something I knew already worked, and I knew just the thing: the “dts” code from Torque3D, which has been in use in some form or another for over a decade.

DTS itself is quite a featured format, being suitable for rendering level geometry with basic culling and fully rigged and skinned character models. In Torque3D there is even a whole content pipeline so you can go straight from collada dae to “compiled” dts shape.

You might be thinking now “Wait a minute, this DTS stuff must be tightly integrated into Torque3D. Won’t I have to include 99% of Torque3D to use this?”

This is where the beauty of libDTShape comes in. libDTShape is an extremely stripped down version of the DTS code from Torque3D. It includes only the essential code which is needed to both load and create a DTS shape, while leaving you to implement the rendering. It lives in its own namespace, so it can work independently of your own code. It is also configurable, allowing you to strip down the code even further (e.g. to remove collada support).

For those who want to just quickly load a shape and see what you can do, don’t worry! libDTShape also includes a basic example OpenGL renderer.



Admittedly as it currently stands libDTShape is a bit of an experiment, but still I hope this can be useful to others.

libDTShape can be found here:


bookmark_borderTorque2D… in a web browser?!

For anyone following the indie game development tool market, there’s one thing that just about every popular commercial tool has: the ability to export your game to the web. Being able to run your code in a web browser is an extremely powerful tool, not only from a platform standpoint but also because it eliminates the requirement of having to install anything.

The tools for doing this in the past sadly either required the end-user to install something (if you made your own plugin), or conforming to a strange runtime (flash, unity, java). Torque itself at one point went with the “make your own plugin” approach, which to say the least was a disaster since every developer had to go through the hurdle of making a plugin for each major system and ultimately the end-user had to install something. Unless your game is the best thing since Minecraft, this approach will never work.

Thankfully now there are several more promising solutions on the horizon, one of which is Emscripten. Emscripten is a compiler that takes standard C/C++ code and compiles it to Javascript suitable for running in any modern web browser. In essence as long as you have a modern 3d graphics card and HTML5-capable browser, you should be able to run just about any game code on all major platforms!

Getting to the point, over the past few weeks I’ve been working on a port of the Torque2D game engine to Emscripten. After a bit of help from the Emscripten developers, nearly everything works (excluding networking).

Torque2D Emscripten

On a time scale, the basic port took a weekend while the bug fixing was spread over the next few weeks. Porting across code to Emscripten was relatively easy since it exposes a pretty standard unix API with SDL, OpenGL, OpenAL, and a few other useful APIs. However the difficulty was multiplied somewhat when I discovered some rather nasty memory corruption bugs.

Firstly there was a problem with the dynamic_cast handler, in which a cast would fail for no apparent reason. It turns out a key map in the input code was a bit too small, causing an overflow which corrupted some memory related to handling the cast. There was also a problem in the scripting engine in which script strings would randomly be corrupted which I ended up hacking around.

Sadly Emscriptens debugging facilities were not up to the task in this case. While there were several facilities to debug memory corruption, none of them picked up on these issues. Unfortunately this meant  I had to go through every major bit of code to eliminate what was causing the problem, which took a considerable amount of time.

Another thing to note is Emscriptens OpenAL implementation was missing a few crucial functions, though these were fairly trivial to implement.

Overall I was quite impressed with Emscripten, though it would be nice if there were more debugging facilities or even some form of GDB frontend so I could more easily step through code.

For your enjoyment, A build of the port can be found here:



bookmark_borderCurrent Status

For those who stumble across this blog, you might wonder why I haven’t updated this blog for over a year. Truth be told I’ve been busy working on a few projects for Mode7 Games such as  Frozen Endzone, which took up a considerable amount of time.

Apart from the problem of not being able to find time to update, I also had a problem of not being to update at all. A while ago I migrated the entire site to Jekyll, a static site generator. This worked fine for a while, but I quickly grew tired of the long delay when regenerating the site when typing up new posts.

I also felt a bit of disconnect needing to type up each post in a text editor and having to guess how the post formatting would turn out. In short it felt like a big chore to post anything. And for me the ability to post things quickly and get instant feedback is a much needed attribute of a blogging system. Thus I have now migrated back to WordPress.

I have a few projects I would like to release before the end of the year, so expect me to write about them here. I’m also going to write about what actually happened this year, including what went wrong during the rather disastrous deployment of the Frozen Synapse server rewrite.

Stay Tuned.