Torque 2D: 3.0 and Editors (soon)
by Michael Perry · 01/23/2014 (3:14 pm) · 75 comments
Torque 2D : 3.0 and Editors
In the last episode of Torque 2D, we had some major progress on the topic of 3.0 and the steering committee. As posted in the On The Road blog, Android support was on its way and we added Mike Lilligreen to the steering committee. After that, T2D progress went dark. The committee has dropped to just myself and Mike, with little progress until a couple of weeks ago. After the holiday break, Mike sent out some e-mails to kickoff the final run of a 3.0 release. All T2D users should take a minute to applaud Mike for keeping things going. So here's where we are at.
Android Available
The Android port is ready for testing. If you pull latest development branch, you can start using it. Developing and testing a new platform is no trivial task. What's most needed is testing, testing, testing. Seriously, if you have an Android device then you need to help out with this. Android support was the #1 feature for a 3.0 release, so any problems with it essentially block 3.0 from happening. At a very minimum, we simply need you to pull development, compile, and run on an Android device. Whether you are successful or you run into problems, please post results in this official thread.New Input Controllers
I've managed to merge the Leap Motion code along with Simon Love's Xbox 360 controller support. Rather than pushing directly into development, I submitted a pull request. You can review the pull request via this link. Once again, what is most needed are testers. We need people to test the Leap Motion, the Xbox 360 controller for Windows, and making sure the platforms are compiling and stable. Even if you do not have the input devices, it would be a huge help if you could apply the pull request and let us know if everything else is working as expected.Linux/Steam OS
An unexpected, yet HUGE pull request cropped up recently. If you take a look at this pull request, you will see Frogger has provided a base implementation for Linux and Steam OS support. Once again, we need help testing the pull request. Apply the patch, then check to see if all the other platforms are still functioning properly. Check Windows, OS X, and/or iOS for stability or compiling errors.If you are feeling especially generous, add on to the code and help Frogger finish the implementation to bring Torque 2D to two new platforms.
Spine
The addition of Spine is a huge step forward for Torque 2D. Supporting Spine is not isolated to a single feature. The implementation adds support for "named cells", vets the SpriteBatch system, and further addresses asset pipeline shortcomings. Mike is currently debugging a few key problems with the Spine implementation:* Sporadic crashes on OS X
* Particles occasionally use the wrong named cell or show a completely square particle
* More features from Simon's branch need to be added
If you can, we need help debugging Mike's development branch. We need to isolate the crash and figure out why some particle emissions are "bad." Once again, this is a blocker for 3.0. The sooner we can solve these problems, the sooner 3.0 can launch...which brings us to the next big point...
Editors
Not everyone can agree on features, platforms, and fixes. Priorities and requests will always vary between users. However, there is one feature request that EVERYONE has agreed to be the most important. I'm talking about editors. To survive, let alone become a highly competitive game engine, Torque 2D needs editors. We've written a few blogs about the topic, yet there hasn't been much movement. After a few months away from Torque 2D, I've decided to reevaluate the editors situation.After receiving permission, I now have the green light to develop editors. In fact, I have already started. Actually, I have a working core editor, plugin system, ImageAsset editor, AnimationAsset editor, AudioEditor, AssetSelector, ParticleAsset viewer, and a few other nice spots.
Now, I'm sure everyone would love to have that. There's one problem. All of the editors rely on a 3.0 release. To be blunt, if 3.0 does not happen, then my editor work can't be released. Once 3.0 is available, I can push my editors to my own fork and we can all push T2D to the next level of user-friendliness. Kind of makes all of my above help requests for coders/testers seem a bit more important, huh? Not only will the engine improve immensely, but it paves the way for an editor suite.
--------------
That's all I got for today folks. Torque 2D is a community project. To have stellar features and editors, the engine needs a driving community. So sound off in this blog and the links I've posted. 3.0 needs your help, otherwise it will be stalled and a great technology could decay. I'm excited to start adding my own features, but 3.0 is the first hurdle. Post your thoughts, testing results, and pull requests so we can move on to the next chapter of Torque 2D.
Regards,
Mich
About the author
Programmer.
#22
It's the a new year. As the CEO and head of biz dev, Eric is very busy with plans for 2014 and 2015. He still likes to hear about Torque progress, but his presence isn't needed for these community projects.
01/26/2014 (6:33 am)
Szzg007 - Quote:Long time no see Eric Preisz it.
It's the a new year. As the CEO and head of biz dev, Eric is very busy with plans for 2014 and 2015. He still likes to hear about Torque progress, but his presence isn't needed for these community projects.
#23
On a side note i have 3android devices
A Yinlips ydpg 18 wit a mali 300gpu and 2.3 android
A Tegra 2 Tablet with 2.1
and
a Sony Xperia Sp. with 4.1
Now with that being sad, enough devices to test.
Will report later.
01/26/2014 (7:47 am)
@Mich am just on the way home, should have it done later tonight.On a side note i have 3android devices
A Yinlips ydpg 18 wit a mali 300gpu and 2.3 android
A Tegra 2 Tablet with 2.1
and
a Sony Xperia Sp. with 4.1
Now with that being sad, enough devices to test.
Will report later.
#24
I'm involved in an open source CMS project, and we've noticed that you need to have these kind of releases or call to actions before people start testing in earnest.
On the one hand, I'm less frustrated now that I notice we're not the only ones having this problem, but on the other hand its kinda sad as well :-(
01/28/2014 (7:30 am)
Looks like it's time to take the Android building instructions and try to get a working result then.I'm involved in an open source CMS project, and we've noticed that you need to have these kind of releases or call to actions before people start testing in earnest.
On the one hand, I'm less frustrated now that I notice we're not the only ones having this problem, but on the other hand its kinda sad as well :-(
#25
01/28/2014 (7:12 pm)
I have last year's Kindle Fire HD, if you have a test project try it on the Kindle.
#26
01/29/2014 (1:26 pm)
@Anthony - T2D comes with over 30 test projects, they are called toys and are part of the Sandbox.
#27
01/30/2014 (6:05 am)
I just closed pull request 137, which included support for LeapMotion and Xbox 360 controller devices. This was confirmed as stable and working by a few different testers. Additional testing inside the development branch would be appreciated.
#28
As you can imagine, this opens a lot of doors. This paves the way for updating to the latest Spine runtime and adding Spriter support. This will make custom character creation much easier, since you can swap out frames by name. 2D content creators will be able to provide reusable assets, making the purchase of 2D art a logical decision again.
01/30/2014 (6:05 am)
Mike has the particle problem resolved and will be submitting a very important pull request shortly. In addition to Spine support, the changes will include the ability to refer to cell frames of an image or animation by name. In other words, you can have assets like this:<ImageAsset
AssetName="soldierWalk"
ImageFile="@assetFile=soldierWalk.png">
<ImageAsset.Cells>
<Cell RegionName="walk1" Offset="2 2" Width="103" Height="66"/>
<Cell RegionName="walk2" Offset="179 100" Width="37" Height="35"/>
<Cell RegionName="walk3" Offset="2 70" Width="65" Height="31"/>
<Cell RegionName="walk4" Offset="161 137" Width="36" Height="41"/>
</ImageAsset.Cells>
</ImageAsset>
<AnimationAsset
AssetName="soldierWalkAnim"
Image="@asset=ToyAssets:soldierWalk
NamedAnimationFrames="walk1 walk2 walk3 walk4"
AnimationTime="1" />As you can imagine, this opens a lot of doors. This paves the way for updating to the latest Spine runtime and adding Spriter support. This will make custom character creation much easier, since you can swap out frames by name. 2D content creators will be able to provide reusable assets, making the purchase of 2D art a logical decision again.
#29
01/30/2014 (6:45 am)
That is one sweet, unexpected feature!
#30
with a bit of your text editor's find and replace feature, you can quickly change the format to look like this:
Some assets have hundreds of sprites packed together, so this is much easier than trying to convert separate x and y values into an Offset = "143 377" field.
01/30/2014 (12:43 pm)
I've also added the ability for TAML to read ImageAsset explicit cells with split offset values. There are some cool open source art assets out there that are packed into a sprite sheet already. The XML file that they come with look like this:<TextureAtlas imagePath="sheet.png"> <SubTexture name="beam0.png" x="143" y="377" width="43" height="31"/> <SubTexture name="beam1.png" x="327" y="644" width="40" height="20"/> <SubTexture name="beam2.png" x="262" y="907" width="38" height="31"/> <SubTexture name="beam3.png" x="396" y="384" width="29" height="29"/> ....
with a bit of your text editor's find and replace feature, you can quickly change the format to look like this:
<ImageAsset
AssetName="Sheet"
ImageFile="sheet.png">
<ImageAsset.Cells>
<Cell RegionName="beam0" OffsetX="143" OffsetY="377" Width="43" Height="31"/>
<Cell RegionName="beam1" OffsetX="327" OffsetY="644" Width="40" Height="20"/>
<Cell RegionName="beam2" OffsetX="262" OffsetY="907" Width="38" Height="31"/>
<Cell RegionName="beam3" OffsetX="396" OffsetY="384" Width="29" Height="29"/>
....Some assets have hundreds of sprites packed together, so this is much easier than trying to convert separate x and y values into an Offset = "143 377" field.
#31
From Mike:
"Asset support for named cells/frames. Frames can now either be specified numerically as before or now with names. Example:
Please take the time to apply this pull request and test on any/all platforms. Check functionality. See if it's stable and if the new features work for you. If you have questions about how to create the assets, just say so. We have plugins for apps like TexturePacker, which can give you the results.
CHIP IN PEOPLE!
01/30/2014 (1:34 pm)
Pull Request 139
From Mike:
"Asset support for named cells/frames. Frames can now either be specified numerically as before or now with names. Example:
<ImageAsset
AssetName="soldierWalk"
ImageFile="@assetFile=soldierWalk.png">
<ImageAsset.Cells>
<Cell RegionName="walk1" Offset="2 2" Width="103" Height="66"/>
<Cell RegionName="walk2" Offset="179 100" Width="37" Height="35"/>
<Cell RegionName="walk3" Offset="2 70" Width="65" Height="31"/>
<Cell RegionName="walk4" Offset="161 137" Width="36" Height="41"/>
</ImageAsset.Cells>
</ImageAsset>
<AnimationAsset
AssetName="soldierWalkAnim"
Image="@asset=ToyAssets:soldierWalk
NamedAnimationFrames="walk1 walk2 walk3 walk4"
AnimationTime="1" />"Please take the time to apply this pull request and test on any/all platforms. Check functionality. See if it's stable and if the new features work for you. If you have questions about how to create the assets, just say so. We have plugins for apps like TexturePacker, which can give you the results.
CHIP IN PEOPLE!
#32
Looking for help early on to get things rolling in the very short term, and to make sure someone else has the "keys" just in case.
A chance to get real experience in remote project and community management, as well as steer its evolution, not to mention setting up a roadmap for two codebases, albeit that will not be the first priority as the current setup for both engines code base is chugging along just fine, even though everyone has much on their plate and full time jobs as far as I know.
Need one or two dedicated, mature individuals ready to commit for a six month cycle. We'll also need quite a lot more help, the scale of commitment being up to you, from punctual to as many hours a week you can spare, to help with community migration/growth, forum moderation, etc.
Work for all, guaranteed ;)
This is obviously all volunteer work, for the greater good !
Contact me for more info
@Mikes (that's Mike plural) : Nice developments, hope to get some hacking time over the weekend
01/30/2014 (5:56 pm)
@Michael : I hear ya, and mostly agree (99.9%) with everything you wrote on complacency, inertia, etc. Wrote a much more extensive reply a couple days back only to hit the word limit for blog replies, and didn't feel like re-writing/editing it to fit the constraints. So, draft saved and full blog post coming from me soonish(tm) on the steps I'll be taking to make something happen :)Looking for help early on to get things rolling in the very short term, and to make sure someone else has the "keys" just in case.
A chance to get real experience in remote project and community management, as well as steer its evolution, not to mention setting up a roadmap for two codebases, albeit that will not be the first priority as the current setup for both engines code base is chugging along just fine, even though everyone has much on their plate and full time jobs as far as I know.
Need one or two dedicated, mature individuals ready to commit for a six month cycle. We'll also need quite a lot more help, the scale of commitment being up to you, from punctual to as many hours a week you can spare, to help with community migration/growth, forum moderation, etc.
Work for all, guaranteed ;)
This is obviously all volunteer work, for the greater good !
Contact me for more info
@Mikes (that's Mike plural) : Nice developments, hope to get some hacking time over the weekend
#33
01/31/2014 (9:03 am)
Szzg007 - I'm still watching ;) We have so many irons in the fire these days and I tend to get caught up in things like contracts, invoicing, operations, and new business development.
#34
github.com/lilligreen/Torque2D/tree/spine
My branch features the latest, up-to-date spine-c runtime and changes in the T2D code to get it working. There is also a SpineToy where you can test things.
Currently only OSX has updated project files! I'd appreciate people helping out and updating the project files for Visual Studio 2010/2012, Android, and Linux. Basically adding the spine folder and it's contents, the SkeletonAsset files in 2d/assets, and the Skeleton files in 2d/sceneobject.
I did make a few changes over the old spine branch in the GG repo. In the latest runtime, all of the spine namespaces changed which let me drop the "Object" from SkeletonObject (the game object is now just called Skeleton - I prefer simple names where possible). Certain static fields were also renamed for consistency with frame based animations, etc.
The "newer" features from Spine - event timeline callbacks, Box2D collision shape creation - are not currently implemented. Please help out if you know how to go about adding this in - or contact the Spine developers and politely recommend they help finish up the implementation as noted in their spine-torque2d runtime ReadMe and Trello board task.
02/01/2014 (10:46 pm)
I won't submit a pull request until the named frame PR is merged into development - but for those that want to jump ahead and start testing basic Spine implementation:github.com/lilligreen/Torque2D/tree/spine
My branch features the latest, up-to-date spine-c runtime and changes in the T2D code to get it working. There is also a SpineToy where you can test things.
Currently only OSX has updated project files! I'd appreciate people helping out and updating the project files for Visual Studio 2010/2012, Android, and Linux. Basically adding the spine folder and it's contents, the SkeletonAsset files in 2d/assets, and the Skeleton files in 2d/sceneobject.
I did make a few changes over the old spine branch in the GG repo. In the latest runtime, all of the spine namespaces changed which let me drop the "Object" from SkeletonObject (the game object is now just called Skeleton - I prefer simple names where possible). Certain static fields were also renamed for consistency with frame based animations, etc.
The "newer" features from Spine - event timeline callbacks, Box2D collision shape creation - are not currently implemented. Please help out if you know how to go about adding this in - or contact the Spine developers and politely recommend they help finish up the implementation as noted in their spine-torque2d runtime ReadMe and Trello board task.
#35
In the case of Mike's named call/frames change from above, you would first add Mike's repository as a remote (you are making your local git repository aware of someone else's repository). Note that I am keeping the remote repo name consistent with the user's github name. This helps immensely when you are applying commits from other branches and you want to easily look back and understand what was merged.
Then we need to fetch the branches from the the other person's repository:
You'll notice that you now have new branches! Doing
will show you the new remotes/lilligreen/* branches available. Now to add the changes from the feature branch that you are interested in testing, simply merge into either your development branch or a feature branch you may be working in. I'd recommend you make sure your working directory is clean of any uncommited changes (You can even use git stash to save them temporarily, more info here: git-scm.com/book/en/Git-Tools-Stashing)
Now assuming you are on branch that is pretty close to the current garagegames development branch, you can now test the changes that have been merged in. (You may be asked to edit the merge commit message after running this command. Just exit the text editor git puts you in.)
Once you have sufficiently built, then tested and tried out any new features that have been added, be sure to comment on the pull request with whether the new changes worked, questions, and concerns. In the case of the named cells/frames change, I'd try to use assets that use it in a module to try it out (Maybe try named assets in the aquarium toy and tropical assets and have fun with it? :P ). Even more helpfully on your comment, explain what platform you are on and any other relevant information about your configuration and how you are building. If you have questions about specific lines of code, you can add comments when looking at a commit on the pull request.
One thing that I've noticed is that some new classes have been added for new features, but they are only getting compiled on whatever platforms the original author developed them on. If you see that new classes have been added in the commit and branch you are merging in, you may want to check that the new files are in the project files for your platform. If they aren't, try adding them to the project file, then if they work, do a git diff and send it to the author so that they can incorporate the project file updates into the pull request.
Once you are done, assuming you haven't made any commits after the last merge above (check the git log first to be sure!), you can now reset the branch you are working in to the state it was in before you did the merge:
Now your branch is back to where you started!
Hopefully this helps for those who would like to test new sets of changes but are scared by git :)
02/02/2014 (2:00 pm)
In case some people are not sure how to properly test changes from other people's branches before they are merged into development, here's some information.In the case of Mike's named call/frames change from above, you would first add Mike's repository as a remote (you are making your local git repository aware of someone else's repository). Note that I am keeping the remote repo name consistent with the user's github name. This helps immensely when you are applying commits from other branches and you want to easily look back and understand what was merged.
git remote add lilligreen https://github.com/lilligreen/Torque2D.git
Then we need to fetch the branches from the the other person's repository:
git fetch lilligreen
You'll notice that you now have new branches! Doing
git branch -a
will show you the new remotes/lilligreen/* branches available. Now to add the changes from the feature branch that you are interested in testing, simply merge into either your development branch or a feature branch you may be working in. I'd recommend you make sure your working directory is clean of any uncommited changes (You can even use git stash to save them temporarily, more info here: git-scm.com/book/en/Git-Tools-Stashing)
git merge lilligreen/development
Now assuming you are on branch that is pretty close to the current garagegames development branch, you can now test the changes that have been merged in. (You may be asked to edit the merge commit message after running this command. Just exit the text editor git puts you in.)
Once you have sufficiently built, then tested and tried out any new features that have been added, be sure to comment on the pull request with whether the new changes worked, questions, and concerns. In the case of the named cells/frames change, I'd try to use assets that use it in a module to try it out (Maybe try named assets in the aquarium toy and tropical assets and have fun with it? :P ). Even more helpfully on your comment, explain what platform you are on and any other relevant information about your configuration and how you are building. If you have questions about specific lines of code, you can add comments when looking at a commit on the pull request.
One thing that I've noticed is that some new classes have been added for new features, but they are only getting compiled on whatever platforms the original author developed them on. If you see that new classes have been added in the commit and branch you are merging in, you may want to check that the new files are in the project files for your platform. If they aren't, try adding them to the project file, then if they work, do a git diff and send it to the author so that they can incorporate the project file updates into the pull request.
Once you are done, assuming you haven't made any commits after the last merge above (check the git log first to be sure!), you can now reset the branch you are working in to the state it was in before you did the merge:
git reset --hard HEAD^
Now your branch is back to where you started!
Hopefully this helps for those who would like to test new sets of changes but are scared by git :)
#36
02/06/2014 (5:59 am)
@Frogger - Fantastic! Thanks for that guide.
#37
02/06/2014 (6:00 am)
@All - Here is the latest e-mail regarding the remaining 3.0 items. Please read carefully and provide your thoughts and feedback:Quote:Here's a list of open points for 3.0:
1. Merge Spine PR (it's coming....)
2. Merge Linux PR
3. Update all platforms with recent source file additions where necessary
4. I've got a bugfix for scene controllers not being read in by TAML correctly, changes are made locally, just need to test then submit PR.
5. I'd like to delete the doxygen Windows executable. It's out of date and the missing mac doxygen.app file weights in at over 70MB - which is way too big for the repo in my opinion. Getting rid of the Windows copy will save us 7MB and we would just update the instructions to point out that users interested in generating their own script reference should download the latest doxygen version first. I honestly doubt many people are interested in this feature, so it won't be much of an inconvenience. I'd also rename the folder from documentation to doxygen to make it more clear.
6. Branch deletions - ok to get rid of RND and Spine in my opinion. What do we want to do with the 64 bit branch and the callbacks branch?
7. PR Queue - the only remaining open pull request after we merge in the top items is for a TextObject, which is more or less a reanimated corpse from the old engine. I'd like to reject this one on the grounds that it doesn't meet certain standards that SceneObject-derived classes should have. To explain:
In my opinion, SceneObject based classes should meet the following criteria:
- rendered objects should exclusively use the batching system for maximum performance
- all objects need to support the Taml serialization structure
The TextObject PR doesn't meet these. I do like the idea of a font class object that uses vector font files, but ideally it would be part of a holistic overhaul of the entire T2D font system - replace gFont with FreeType or something else, add a FontAsset, etc. Any comments regarding the PR itself or my proposed "standards"?
#38
1. Last big feature, which should wrap up the reduced 3.0 plan. Let's get it going
2. This will need testing from several folks, but so far it seems promising.
3. I'll handle the Windows/VS projects. I can also take a stab at the Linux platform, once it's in the dev branch. It looks Mike has OS X covered. What about iOS and Android?
4. Go for it. I'll test and push this in.
5. I'm fine with this. An alternative process for generating docs outside of the repository can be figured out.
6. I want to archive the callbacks branch, as it might be useful to implement later. Nuke 64 bit support, since no one is maintaining it.
7. I agree. It's a start, but not finished enough to accept. We should better document the full acceptance for new objects exposed to script, especially if they can be serialized.
02/06/2014 (6:02 am)
My thoughts on the remaining list:1. Last big feature, which should wrap up the reduced 3.0 plan. Let's get it going
2. This will need testing from several folks, but so far it seems promising.
3. I'll handle the Windows/VS projects. I can also take a stab at the Linux platform, once it's in the dev branch. It looks Mike has OS X covered. What about iOS and Android?
4. Go for it. I'll test and push this in.
5. I'm fine with this. An alternative process for generating docs outside of the repository can be figured out.
6. I want to archive the callbacks branch, as it might be useful to implement later. Nuke 64 bit support, since no one is maintaining it.
7. I agree. It's a start, but not finished enough to accept. We should better document the full acceptance for new objects exposed to script, especially if they can be serialized.
#39
02/06/2014 (6:09 am)
Don't nuke the 64bit branch, new computers are 64bit. Even if nobody is maintaining it now, someone could in the future. A good example of this is t3d's linus r&d branch that was abandoned but that has inspired the new opengl/linus fork.
#40
1. Been working on Spine in my own branch and I strongly believe that we can't make a complete integration possible for 3.0.
I believe however that a more stable integration should be the target for 3.0.
For example, if you specify a SkeletonObject's Angle or BlendColor, the changes do not apply to the Spine Skeleton. It's an easy fix (look for my updated branch + blog in the following hours) but to me that's what the implementation needs to cover : Having a spine-based object behave like any other SceneObject.
2. All for it, can't test it personally.
3. Android works (successfully compiled and tested the Sandbox) but we need to be careful about what is added to it. Imho, the Android port is functional but not production-ready.
4. integrated in my work branch, didn't test.
5. I go straight to the source for documentation.
6. Nuke all branches from orbit. Keeping callbacks is a nice idea but I doubt people will stand up to finish the project as all it does is 'prettify' the path that leads to Con::executef.
Further work on Spine or other systems can easily be branched off after 3.0 anyways.
7. Standards should be the entry-level qualifier for additions to the official repo. Users should be able to have branches on their own github accounts and publicize their work via the usual channels (GG forums, G+ page).
02/06/2014 (6:23 am)
Here are my thoughts :1. Been working on Spine in my own branch and I strongly believe that we can't make a complete integration possible for 3.0.
I believe however that a more stable integration should be the target for 3.0.
For example, if you specify a SkeletonObject's Angle or BlendColor, the changes do not apply to the Spine Skeleton. It's an easy fix (look for my updated branch + blog in the following hours) but to me that's what the implementation needs to cover : Having a spine-based object behave like any other SceneObject.
2. All for it, can't test it personally.
3. Android works (successfully compiled and tested the Sandbox) but we need to be careful about what is added to it. Imho, the Android port is functional but not production-ready.
4. integrated in my work branch, didn't test.
5. I go straight to the source for documentation.
6. Nuke all branches from orbit. Keeping callbacks is a nice idea but I doubt people will stand up to finish the project as all it does is 'prettify' the path that leads to Con::executef.
Further work on Spine or other systems can easily be branched off after 3.0 anyways.
7. Standards should be the entry-level qualifier for additions to the official repo. Users should be able to have branches on their own github accounts and publicize their work via the usual channels (GG forums, G+ page).
Employee Michael Perry
ZombieShortbus