Runtime refactoring

April 17th, 2013

Implementing all the runtime over and over (and over) for various toolkits in multiple languages has highlighted where things can be improved. I’ve just committed some refactoring for all the official runtimes (except spine-corona, which will see some attention soon). I’m now pretty happy with how they are working, so it is unlikely that there will be further refactoring like this. Sorry if this breaks your code, but it shouldn’t be too hard to fix up.

Most classes now only store data, without anything specific to rendering. The exception is an atlas page, which needs a reference to the texture for that page. Writing a renderer just means going through the data objects and rendering them. Extending a generic runtime is cleaner and takes very little code, especially for spine-c which now uses much less weird C OOP. Eg, extending spine-c for SFML is done in ~100 lines of code.

This refactoring also enables use of an atlas with multiple backing pages for C#, XNA, cocos2d, and cocos2d-x. SFML is now the only runtime that supports only a single page atlas.

We now have a pretty solid foundation for the existing runtimes. Up next is to bring spine-corona up to date, separate it into a generic Lua runtime, finish the Torque2D runtime, and create something for 2D Toolkit users.