Torque 2D: The Big Update List
by Michael Perry · 01/03/2013 (6:56 am) · 43 comments
Legacy vs New
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:Torque 2D MIT Coming Soon
The Future of Torque 2D is Open Source!
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.
Similarities
- 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
Differences
- 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.
New Features
- Box2D physics
- Simpler and flexible sprite objects
- New GUI controls that use sprites
- Composite sprites
- Asset system
- TexturePacker Support
- Module system
- TAML serialization format (like XAML and XML)
- Batched rendering
- Multiple collision shapes
- Behavior connections
- Built-in unit testing framework, cross platform
General Improvements
- Improved rendering pipeline
- Massive performance increase
- Cocoa API
- World query system (faster picking, by area or pick by collision shape)
- More detailed debug metrics
- Faster triggers
- 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
Deprecated Features
- 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
Next Up
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.
- Mich
About the author
Programmer.
#2
I can understand why you're not releasing the GUI editors with the initial release but do you plan to include some example projects?
01/03/2013 (7:48 am)
Nice update you got there.I can understand why you're not releasing the GUI editors with the initial release but do you plan to include some example projects?
#3
01/03/2013 (7:52 am)
Looks like great changes. Personally I never liked the old editors so hopefully new editors will be much better.
#4
01/03/2013 (7:52 am)
@Joe O - Yes, there will be sample modules that can be pieced together to make a game. We will have one such game, which is the Apocalypse Demo. 
#6
As Steve said, the *massive* performance improvement caught my attention as well!
01/03/2013 (9:36 am)
Looking good! The biggest part that worries me is the lack of tilelayer and tilemap. I'm using these heavily in my current project and use the built in A* logic as well. I'd like to hear more on how the sprite layering will work as a replacement to this?As Steve said, the *massive* performance improvement caught my attention as well!
#7
The above produces this image:
Tweaking the code to the following:
Produces this image:
01/03/2013 (9:42 am)
@Bruno - The "tile" creation is basically driven through composite sprites. We still need to work on getting paths back in the engine, but we haven't fully decided on that implementation. As for the composite sprites, here is some sample code:%composite = new IsoCompositeSprite();
testScene.addToScene( %composite );
%composite.BatchIsolated = "true";
%composite.BatchSortMode = "-y axis";
%composite.setDefaultSpriteStride( 2.5, 1.2 );
%composite.setDefaultSpriteSize( 5 );
for ( %y = -5; %y <= 5; %y++ )
{
for ( %x = -5; %x <= 5; %x++ )
{
%composite.addSprite( %x, %y );
%composite.setSpriteImage( "{MelvTesting}:isotiles2", getRandom(0,4) );
}
}The above produces this image:
Tweaking the code to the following:
%composite = new CompositeSprite();
testScene.addToScene( %composite );
%composite.BatchIsolated = "true";
%composite.setDefaultSpriteStride( 5, 5 );
%composite.setDefaultSpriteSize( 5 );
for ( %y = -5; %y <= 5; %y++ )
{
for ( %x = -5; %x <= 5; %x++ )
{
%composite.addSprite( %x, %y );
%composite.setSpriteImage( "{MelvTesting}:MiniTileMapImage", getRandom(0,15) );
%composite.setSpriteAngle( getRandom(0,360) );
}
}Produces this image:
#8
01/03/2013 (9:47 am)
It was our opinion that pathfinding should not have been so heavily bound to tilemap and tilelayer. We want to work on an implementation that is more loosely coupled and can be updated without breaking each other. 
#9
01/03/2013 (11:19 am)
Basically, if you're familiar with (i)T2D the engine will feel very familiar, but there are dozens of systems that have been overhauled, updated or straight-up replaced. Ramp-up time should be pretty short, but there are some "head-space" paradigm shifts that might take a little longer to sink in (design changes that will affect how you approach tasks). All-in-all, it's pretty awesome. 
#10
You guys are doing great work on this, I look forward to seeing your next blog.
01/03/2013 (1:15 pm)
I'm a big tilemap person myself so I am very interested to see more on this sprite system.You guys are doing great work on this, I look forward to seeing your next blog.
#12
01/03/2013 (9:33 pm)
I'm glad there will be a Mac version at launch 
#13
01/04/2013 (1:57 am)
Any guess as to how long it will take to start having editors come out?
#14
1. What framework should we use for the editors?
2. What editors do we want?
3. In what order should we create the editors?
4. Do we want to rely on 3rd party tools, like TexturePacker?
These are questions that need to be answered after the launch before we start developing any tools. After that, it's matter of how many people contribute to the effort. It would take one person quite a while to replace all the past editors. Five people could get it done much faster.
01/04/2013 (5:54 am)
@Chase - That all depends on you, meaning yourself and the rest of the community. I will also put together a steering committee. I've talked about it in past blogs. There are some important questions to ask first:1. What framework should we use for the editors?
2. What editors do we want?
3. In what order should we create the editors?
4. Do we want to rely on 3rd party tools, like TexturePacker?
These are questions that need to be answered after the launch before we start developing any tools. After that, it's matter of how many people contribute to the effort. It would take one person quite a while to replace all the past editors. Five people could get it done much faster.
#15
Framework - is QT an option?
Tool chain is extremely important and is what separates the men from the boys in the eyes of efficiency and time to market especially when working on a new IP. Most important for us is cross platform abilities. We have had to seek other means for a game that will be releasing on iOS and Android in February, because we wanted to hit the iOS /Android/HTML5 markets. It would sure be nice if T2D could boast PC, Mac, Linux, iOS, Android and HTML5 as its available platform targets. Obviously this can come later, but should be extremely high on the list as the more markets you can accurately cater to the more folks we can have looking at T2D. We would love to stick with Torque explicitly. Nothing worse than trying to get one game to extend onto just one more platform before launch and have to learn a whole new language just for him....sigh.(it is what it is I guess...lol)
3rd party tools are a must in my opinion, Texture Packer is awesome. We use it consistently for creating sprite-sheets/atlas's and Mr. Loew is on top of things about keeping it up to date and support. He also produces Physics Editor which can really help you get down and dirty with collision polys. Sad part is when we pull down the data formats drop down we see ever engine under the sun but T2D :-(
Just my 2cents :-) Great job Michael, hope this new product makes T2D a household name :-)
01/04/2013 (8:02 am)
We have a game releasing to the major portals this month (barring paperwork...ugh) that was match 3 based and tile maps were used explicitly with this. Actually, I had put together a match 3 engine based on this for us moving forward, which is my concern. Sounds like I will have to rewrite everything now. Don't get me wrong, I'm all for it as long as the new system allows us to just do things better :-) Framework - is QT an option?
Tool chain is extremely important and is what separates the men from the boys in the eyes of efficiency and time to market especially when working on a new IP. Most important for us is cross platform abilities. We have had to seek other means for a game that will be releasing on iOS and Android in February, because we wanted to hit the iOS /Android/HTML5 markets. It would sure be nice if T2D could boast PC, Mac, Linux, iOS, Android and HTML5 as its available platform targets. Obviously this can come later, but should be extremely high on the list as the more markets you can accurately cater to the more folks we can have looking at T2D. We would love to stick with Torque explicitly. Nothing worse than trying to get one game to extend onto just one more platform before launch and have to learn a whole new language just for him....sigh.(it is what it is I guess...lol)
3rd party tools are a must in my opinion, Texture Packer is awesome. We use it consistently for creating sprite-sheets/atlas's and Mr. Loew is on top of things about keeping it up to date and support. He also produces Physics Editor which can really help you get down and dirty with collision polys. Sad part is when we pull down the data formats drop down we see ever engine under the sun but T2D :-(
Just my 2cents :-) Great job Michael, hope this new product makes T2D a household name :-)
#16
I agree that adding more platforms is going to be very important to the success of the new T2D. I've certainly doubled my experience on platform support after working on the new OS X code. Thanks for the comments George.
01/04/2013 (8:17 am)
Quote:Framework - is QT an option?Absolutely. In my opinion, this should the top choice to investigate. A few people disagree with me, thinking the Torque GUI system is more ideal. After spending a couple years working on editors using Torque GUI, I can safely say it is one of the worst options. This is going to be a lengthy and probably passionate discussion, which I look forward to.
I agree that adding more platforms is going to be very important to the success of the new T2D. I've certainly doubled my experience on platform support after working on the new OS X code. Thanks for the comments George.
#17
01/04/2013 (8:38 am)
Your more than welcome, I'll definetly support QT. I use it in another language I develop applications in and have a passion for it :-) I cant imagine the GUI system in T2D even being close... :-)
#18
Great work so far guys! I can't wait to get my hands on the new T2D!
01/04/2013 (10:44 pm)
I'd like to echo the previous concerns over the lack of tilemap support. We're working on our second RPG, so obviously we rely heavily on tilemaps. I can see how in theory the composite sprite system could be used to render maps, but in practice I'm really not going to want to be generating 500x500 (or larger) maps with several layers manually in script. Now, if you could add in support for loading a TMX file directly into a CompositeSprite to generate a tilemap in one call, that would be awesome! :)Great work so far guys! I can't wait to get my hands on the new T2D!
#19
1. Composite sprites will be what you should use as a replacement for the old tilemap system
2. The lack of a tile editor is temporary, it just will not be available at launch
3. The decision of when and what the map editor will be is completely up to the the community. If it is that important, then we will likely make it one of the first editors we create.
As for TMX support, this is a great idea. I think we should support several asset formats we do not create, such as TMX, Sprite filers, TexturePacker, and more.
01/05/2013 (4:12 am)
@Adam - Thanks for chiming in. Your concerns are understandable. I'll be clear on three things:1. Composite sprites will be what you should use as a replacement for the old tilemap system
2. The lack of a tile editor is temporary, it just will not be available at launch
3. The decision of when and what the map editor will be is completely up to the the community. If it is that important, then we will likely make it one of the first editors we create.
As for TMX support, this is a great idea. I think we should support several asset formats we do not create, such as TMX, Sprite filers, TexturePacker, and more.
#20
01/05/2013 (10:06 pm)
Well I can't code the editors, but I'm willing to help make video tutorials when the time comes :) 
Associate Steve Acaster
[YorkshireRifles.com]
The most favoured improvement in anything ever! :)
Nice read, looking good.