Game Development Community

dev|Pro Game Development Curriculum

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
#41
02/06/2014 (7:02 am)
The assumption I made with the 64bit branch was that it would be merged into the main tree. This seems to be fairly unlikely since nobody seems to be interested in this feature despite the increasing prevalence of 64bit systems (e.g. osx, ios, win64, ...). Unfortunately I do not have the resources to constantly keep up with developments in the main tree especially if my efforts are not being taken seriously.

I'm also not too sure what the problem with merging it in is. Its just adding some platform types for 64bit systems, updating the project files, correcting a few types so the compiler doesn't complain, and expanding reserved area for the stringtable pointers in the scripting bytecode.

I admit, modifying TorqueScript bytecode is scary but I did check everything afterwards *plus* I double checked the node sizes were expanded correctly to factor in the extra U32 per string table entry. Not sure what else I can do on that front.

Considering this, I make the following suggestion:

Since its evident anything which touches TorqueScript is shrouded in fear and uncertainty, I suggest in a future release either of the following is done:

A) Ensure the TorqueScript system has a robust set of unit tests so nobody has to rely on some other guy to make sure nothing breaks.

B) Ditch TorqueScript and migrate to a scripting language which is actively maintained.
#42
02/06/2014 (7:34 am)
@Simon: I am curious about what in the android build is not ready for production. Maybe I can help bridge that gap.
#43
02/06/2014 (7:49 am)
Hey Tim!

Bear in mind that I'm no expert on Android dev.

Based on a clean compile of the latest dev branch, exported as a signed .apk on a Galaxy Tab 10.1, the following issues occur

- Multi-touch doesn't work, I've made some script checks and number of touches is always 1. So, no zooming. Might be related to the replacement of fvalue, fvalue1, fvalue2, etc. by fvalue[x] in the Xinput/Leaptoy modifications.

- Angle Toy in the sandbox simply does not detect the "mouse position"

- Sounds don't stop when switching out of the application.

- Wireframe mode draws filled polygons (making it really hard to see what's going on if there's a background sprite)

- ShapeVector doesn't draw polygons at all, just circles.
#44
02/06/2014 (8:06 am)
Edited to reflect some iOS testing:

-Does multitouch work on iOS without the apple gestures? If I remember correctly i implemented touch on android in the same manner as iOS. But there could be a bug in there.

-Angle toy does not work on iOS either so this is either a bug in the angle toy or something with mobile touch input.

-wireframe mode does not work on iOS either so this is likely due to an opengl es bug.

-Shapevector does not work on iOS either so most likely a bug in opengl es as well.

-The audio thing may just be an android bug I missed since sandbox does not have audio anywhere.

#45
02/06/2014 (8:23 am)
@Tim : No iOS or OSX device here so I can't help on that front.

You can try Mike Lilligreen's audio test module but you will have to convert the music files (located in the Toyassets folder) to 44.1 Khz, 16 bit stereo files. The sound effects work fine.
#46
02/06/2014 (3:10 pm)
I wasn't on the steering committee at the time, but it was probably a mistake to have had the 64 bit changes sitting out in a feature branch. The intent was fine, but I can't recall anyone in the past offering testing feedback on any of the branches outside of development. I understand most people just want to take the master branch and make games, but at the same time if you expect the engine to improve, something has to give.

I'll try to find some time in the next couple days to pull the 64 bit changes into a copy of the latest dev branch. I don't think this should just disappear.
#47
02/07/2014 (11:49 am)
@Mike

Thanks for looking into this, I appreciate it. :)
#48
02/08/2014 (8:13 am)
Well, I got the branches to merge but busted the VS2010 and Xcode projects in the process. I haven't had the chance to fix things and test. If anyone wants to help in the repair process, my 64 bit branch is here:

github.com/lilligreen/Torque2D/tree/sixtyfour
#49
02/09/2014 (8:53 pm)
I have a question about the android port of Torque2D...When I compile it through Eclipse it shows an error about needing Leap.h...I added another include location in Android.mk, But now it brings up a lot of errors from Leap.h...Would the Leap SDK be necessary in the Android port?
#50
02/10/2014 (5:49 am)
Leap code wasnt in there when I wrote the port and committed it so I assume it was merged in after. Does the leap even work on android? Sounds like its needs a define to exclude it.
#51
02/10/2014 (6:14 am)
Leap should not have been merged in. When I merged the rnd branch, it was basically just the Leap Motion feature. This introduced one or two new source files for the core engine, but the Leap Motion feature should only be made available on OS X and Windows.
#52
02/10/2014 (6:41 am)
Okay...I was using the development version...Is there a different version that also has an android port?...Michael is the rnd port merged in with the updates?
#53
02/10/2014 (6:47 am)
Development should always be considered unstable, especially as we start merging branches for a release. The rnd port has been merged and can be nuked soon. Someone just needs to hop into the Android mk files and check for errors, such as removing any Leap source files from being included.
#54
02/10/2014 (7:15 am)
Later today I will work on that unless someone gets to it sooner. I would be glad to help out.
#55
02/10/2014 (11:20 am)
Just to let everyone know, editors for Torque 2D would be a side project of mine. This is outside of GG and even outside of the steering committee. That's why all work would happen in my own fork and separate from the main repository. The pacing, feature order, and distribution would be at my discretion based on the time I have available.

The reason it was included in this blog was to grab people's attention so they would read about the more immediate and pressing need for a 3.0 push of the engine.
#56
02/10/2014 (7:42 pm)
The Linux pull request should be ready to go, spine support looks to be working.
#57
02/11/2014 (4:42 am)
I'm going to test iOS as well to see if the same problems Simon reported on Android are happening on iPhones. I've confirmed that multi-touch works fine on iOS in the latest development branch.
#58
02/11/2014 (5:03 am)
iOS test case:

1. Open modules/MoveToToy/1/main.cs.
2. Add the following line at the top of MoveToToy::onTouchDown
echo(%touchID);
3. On iOS when I touch with one finger, the console should print 0
4. If I press with one finger, leave it down, then press with another finger, I get 0, then 1 in the console

#59
02/11/2014 (5:05 am)
Testers have been more or less saying the same thing. Quoting practicing01:

Quote:oh btw i've pulled the latest t2d linux which includes the spine stuff. compiles/runs on 32bit, runs on 64bit (haven't tried compiling on 64bit)

linux still has some bugs, probably relating to sdl but nothing major

all of the toys worked

I've heard the same kind of results from Frogger and Simon Love. We are compiling notes on the remaining work for 3.0 and will be posting those to the wiki shortly.
#60
02/11/2014 (8:56 am)
I worked with practicing01 to resolve the Android compiler errors. They were indeed due to the input changes made for Leap support. His commit of the fixes can be found here. To summarize, any references to touchesX/Y/ids needs to be replaced with fingers. Also, fValue has been replaced with fValues (an array). The fixes will be manually merged into development, rather than a pull request.

However, multi-touch is still nonfunctional on Android.