Much of the content of this blog is aimed at informing previous T2D and iT2D users about the major differences between the old technology and the new Torque 2D MIT code. If you are just now finding out about the upcoming MIT release, you can read these past blogs:
This blog is going to cover the major differences at a very high level. I plan on posting more blogs each week that will cover systems in greater detail, but I am more than willing to answer questions in the comment section. Anyone who plans on porting their project will want to read these blogs carefully.
Veteran users who plan on creating a new project with the MIT codebase will also want to read up on the new features before planning out game systems. All in all, a huge portion of the engine has been rewritten, so let's get to it.
C++ core engine: The base T2D engine is still written in C++, with some C mixed in. The iOS and OS X side utilize C++, but also mixes in Objective-C.
TorqueScript: No major enhancements. Still used primarily for developing game play.
Low level inheritance: The base classes are still present: ConsoleObject, SimObject, SceneObject, SimComponent (not in that order)
Core support systems: There have been some improvements, but the code for handling memory, strings, console, etc, is still present
Behaviors: The base behavior system is still there, but we have added new features to it. You can still create components in C++ and BehaviorTemplates in TorqueScript
Many GUI controls: The vast majority of GUI controls are still present, such as GuiButtonCtrl, GuiRadioCtrl, and so on. However, we have added new controls for representing images that you should use instead of the old controls. More on this later
More Objective-C: The OS X rewrite has introduced a lot more Objective-C due to utilizing more Cocoa API. This was necessary to replace the Carbon code.
Editors vs API: The initial launch of Torque 2D MIT will not have any editors. It will be a pure API with example code for game play, assets, GUIs, and unit tests.
Persistence: The old serialization format is essentially gone. With the exception of GUI profiles, anything saved to file will be in TAML format. More on this later.
Sprite system: We have unified the sprite system. t2dStaticSprite and t2dAnimatedSprite have been combined into 'Sprite'. The class hierarchy is a bit more complicated that this description, but I can cover that more later.
Asset system: Plain and simple, there was not a managed asset system for the older 2D engines. We just had loose files and TorqueScript objects that pointed to them. Now, the new Asset system completely changes how you manage sprite images, animations, audio, level files, GUIs, and more.
Updated libraries: We have updated the OpenAL, ljpeg, and lpng libraries to the very latest version. We are also using the latest Box2D SDK.
World query system (faster picking, by area or pick by collision shape)
More detailed debug metrics
Scrollers can use image frames
Better image processing (all images are cells, no image modes, huge performance gain)
Stock color in TorqueScript (yay cornflower blue)!
GUIs can use assets, instead of loose file references for images
Widespread cleanup of the code itself
All TorqueScript organized into modules
Removed redundant prefixes, reorganized the entire file and project structure for the source
All editors: It's been covered before, but all of the previous TGB editors have been culled out. The majority of the code will not work with the new systems.
Datablocks as assets: No more t2dImageMapDatablock, t2dAnimationDatablock, and so on. This has been replaced by the superior asset system.
3D shape rendering: This was a change made to iTorque 2D that has been carried over to the new T2D. This mainly affects old T2D users.
Level datablocks: iTorque 2D users needed to use level datablocks files for performance reasons. This is no longer necessary with the superior asset system which features faster loading, smart reference tracking, and automatic unloading.
Realtime resizing of objects with collision bounds: This is a limitation imposed by Box2D. Because objects have collision shapes and joints, you cannot dynamically resize sprites with collision shapes without first destroying the shape and joints and rebuilding them after resizing has finished.
World limits: Sprites no longer have a world limit property built in. You can easily implement this functionality using Box2D triggers
Linkpoints: The linkpoint system has been replaced by Box2D joints, which are more performant and contain more features.
TileLayer and TileMap: This entire system was rendered obsolete by the new composite sprite system. More details on this later.
Particle system: This is still somewhat up for debate. The old particle objects can still work, but we are changing the serialization. It is my hope we can replace the current system with something much simpler later on.
TextObject: The scene object that was used for rendering text has been nuked. It was a broken mess that will get a more suitable replacement
As I said at the top of this blog, this was a very high level list of changes. I'm sure a few of you might be getting close to hitting the panic button at this point, especially if you are using tilemaps, particles, or many datablocks. Hold off on hitting that button until you are able to read my next few blogs. I'll start with a very detailed writeup on the new sprite system, which should be landing early next week. In the end, it will be worth it when you can make use of amazing improvements like this:
Our new asset system also allows us to quickly add support for other tools, like TexturePacker:
That's a total of 2,500 isometric tiles with 1,000 animated sprites, rendering in only two draw calls at frame rates in the hundreds. It was created using only 20 lines of TorqueScript code, written in about 15 minutes. Thanks for taking time to read this blog. More 2D goodness coming soon.