Torque 3D 3.6.1 released!
by Daniel Buckmaster · 10/08/2014 (4:29 pm) · 49 comments
It's been a long six months and a rough road, but the Steering Committee is very happy to announce that version 3.6.1 of Torque 3D is finally ready! As the first release this Committee has been in charge of, it's taken a bit longer than we'd have liked, and we've learned a lot about the process and our own abilities. But we're happy with the result, and we hope you will be, too! Without further ado-

The new outpost test level, thanks to Azaezel
Give me everything! - git pull - from GarageGames - from GitHub
Only interested in the Full template - from GarageGames
Just the binaries, thanks - Windows 32-bit - Windows 64-bit
You can also grab them from the downloads page of the wiki. The rationale for this new download format is that people who will be evaluating the engine can just download the Full template, not the entire repository. And people who are interested in getting the source code probably don't need the precompiled binaries - but if they need them, they can still get them.
Please note: we've had some reports of trouble with these binaries. If you have any difficulty, please make a GitHub issue, or post in the forum.
Sorry for any confusion! We're still new to this, and it's been a valuable learning experience.
There are a couple of cool pages I'd like to point out. First is the made with Torque page, which looks really boring now but offers a great opportunity - by using the form at the top of the page, you can add a page for your own game or Torque project which will then be listed on the main page. This is something we didn't have the ability to do with the current landing page, and we're really excited it's possible now. It's looking a little sad at the moment, but I have no doubt it will start filling up soon.
Secondly, there are two pages - portable tutorials and TDN guidelines - which are great starting places for contributing to the wiki. The first one is a place for authors to add links to Torque tutorials or resources they have written and would like to have moved to the wiki. The second lists a bunch of TDN pages which meet GarageGames' guidelines for inclusion in this open wiki. So if you're itching to contribute to Torque in any way - get on those!
With that in mind, after 3.6 is released, and tagged v3.6, we will make a branch development-3.6 which will contain versions 3.6.1, 3.6.2, etcetera. This branch will contain only bugfixes with a sufficiently small scope - no large refactoring, no need to change your game code, just incrementally more stability. This is intended to give developers a stable place to work while still receiving updates.
This means that pull-requests which just contain bugfixes should be sent to the development-3.6 branch. We know this isn't going to be easy for everyone, so we'll put some effort into making the process easy - doing manual merges ourselves and so on.
We're looking for people who have a passion for improving the engine technology that allows others to make whatever they set their hearts to - it's really more about effort and willingness to participate than raw programming talent! We also welcome people of any skillset - artistic talent is a noted deficiency among the current committee members, and we wouldn't mind someone who's passionate about community development, publicity, etcetera!
So if you think you have something to offer and you want to see Torque become the open-source game engine of choice, then send us your details!

The new outpost test level, thanks to Azaezel
Downloads
For this release, we've decided to provide several ways for you to get your hands on the engine. As usual, you can use git, or download a snapshot of the entire repository from GarageGames - this time, though, it doesn't come with precompiled binaries. However, you can also now download only the Windows binaries, which you can drop into your existing project. And finally, we've provided a separate download of the Full template, with compiled executables and assets, which we hope will be a more convenient way for people to evaluate the engine's features without having to download the entire source code and everything.Give me everything! - git pull - from GarageGames - from GitHub
Only interested in the Full template - from GarageGames
Just the binaries, thanks - Windows 32-bit - Windows 64-bit
You can also grab them from the downloads page of the wiki. The rationale for this new download format is that people who will be evaluating the engine can just download the Full template, not the entire repository. And people who are interested in getting the source code probably don't need the precompiled binaries - but if they need them, they can still get them.
Please note: we've had some reports of trouble with these binaries. If you have any difficulty, please make a GitHub issue, or post in the forum.
What happened to version 3.6?
That was my bad. This announcement was supposed to be for the release of version 3.6. However, due to over-eagerness, I hit the 'merge to master!' button before we'd done enough testing, and discovered a significant bug in the 64-bit version of the engine in Windows 8. Rather than quietly overwrite the repository history and hope nobody noticed, we decided to fix the issue and publish a new minor version, 3.6.1. We got the chance to test our our shiny new support branch (more on that below), and in the process also fixed some art issues that cropped up after 3.6 had happened.Sorry for any confusion! We're still new to this, and it's been a valuable learning experience.
Changelog
So what's new in version 3.6.1? I'm glad you asked. I mean, I would have told you anyway, but it's nice when you ask. Here's a brief summary of the most significant changes:- You can now compile 64-bit executables! This means your game can take full advantage of 64-bit operating systems. This one was a long time in coming, with a number of contributors throughout the process. Unfortunately it's not supported by the Project Generator, so you'll have to use CMake unless you want to fiddle with your Visual Studio files manually (or submit a pull-request to fix it!).
- Speaking of CMake, we officially support it for the first time! If you've never heard of CMake, it solves the same problem as the Project Generator - taking care of the work of generating build files for different compilers from a single representation. Here's a tutorial for the uninitiated.
- You can now compile with Visual Studio 2013. CMake can generate native VS2013 solutions, or you can generate 2010 solutions with the Project Generator and let VS013 update them for you. This is a great step towards making Torque compatible with modern tools.
- The googletest library is now available for your unit test suites. You are writing unit test suites, aren't you? The good news is we plan to expand our use of unit testing greatly in the coming releases, as well as adding integration testing and, if we can swing it, testing across network connections.
- An actual new feature that you might use when you're, like, making a game, is that you can now use the names of some common colours instead of specifying RGB values - the same as in Torque 2D. Some classic examples include Black, Red, Green, and CornflowerBlue. The full list of named colours is here.
- There are, of course, tons of small (and big) bugfixes and improvements. A major one you might notice is that now, when connecting to a server, shapes with animations will play synchronised on each client, rather than having each client start from the beginning of the animation. This is especially noticeable with long-running non-sequential sequences. There's also been some huge passes over the whole codebase to, for example, improve our consistent usage of platform-independent types like U32, S32, F32, etc. And subtly, we've been laying the groundwork for some awesome changes coming in the future - Assimp, Linux, and a few more things.
What this version means for you
Fortunately (or possibly unfortunately) there shouldn't be a lot of impact on your games. The new version of the engine should be pretty non-disruptive, except for a couple of specific areas.- If you've made changes to your project's main.cs file, have a look at the new closeSplashWindow function, and the Canvas's displayWindow property. Your game will continue to work fine, but the T3D splash window will now stay visible until you dismiss it explicitly. The Template main.cs files handle this properly, so if you haven't changed your main.cs, you can just update from those.
- The old unit testing framework has been removed in favour of googletest, the framework used by T2D. Sorry for the rapid change, but we little evidence to believe people were taking advantage of the test runner, so we moved quickly. Almost all current unit tests have been ported, and many more are on their way.
- If you've made your own Project Generator modules, be sure to update all uses of the Generator class to T3D_Generator. It was renamed to avoid a conflict with a built-in PHP5 feature.
- The Player class now uses the swimForce datablock member instead of runForce when moving in water. If your game involves lots of moving in water, you might need to edit swimForce from its default to ensure your movement works as expected.
- If you had edited the stock code dealing with the ShapeBase::Thread::sound member to actually do something, we apologise for any merge conflicts we've caused by removing that dead code.
The wiki?
Wait, what? Yes, we have a wiki now! Here it is. With huge thanks to Lukas Joergensen who spearheaded the effort to set it up, and is the owner of the wiki until the request to turn it into a community gig is approved. Jump on board and have a look around! Anyone can edit for now, so if you see something that's not finished, lend a hand!There are a couple of cool pages I'd like to point out. First is the made with Torque page, which looks really boring now but offers a great opportunity - by using the form at the top of the page, you can add a page for your own game or Torque project which will then be listed on the main page. This is something we didn't have the ability to do with the current landing page, and we're really excited it's possible now. It's looking a little sad at the moment, but I have no doubt it will start filling up soon.
Secondly, there are two pages - portable tutorials and TDN guidelines - which are great starting places for contributing to the wiki. The first one is a place for authors to add links to Torque tutorials or resources they have written and would like to have moved to the wiki. The second lists a bunch of TDN pages which meet GarageGames' guidelines for inclusion in this open wiki. So if you're itching to contribute to Torque in any way - get on those!
A new branch
Now that we're somewhat on top of our process, we're going to be introducing a small change in how the repository is run. At the moment, the development branch is where all work is merged in and tested before 'releasing' to the master branch. This works fine, but it forces users to upgrade to the next engine version if they want access to bugfixes. While we're shying away from significant changes to the engine's API (for now - more on that later), some users may just want fixes, not new features.With that in mind, after 3.6 is released, and tagged v3.6, we will make a branch development-3.6 which will contain versions 3.6.1, 3.6.2, etcetera. This branch will contain only bugfixes with a sufficiently small scope - no large refactoring, no need to change your game code, just incrementally more stability. This is intended to give developers a stable place to work while still receiving updates.
This means that pull-requests which just contain bugfixes should be sent to the development-3.6 branch. We know this isn't going to be easy for everyone, so we'll put some effort into making the process easy - doing manual merges ourselves and so on.
Community projects and the future
With that said, there are a number of exciting community projects that are close to fruition. BeamNG's OpenGL/Linux ports are the most prominent, but there's also the hard work being done to modernise Torque's renderer with deferred shading, and the redesign of the core gameplay classes with an entity/component system. Along the same lines as the 'made with Torque' wiki page, we've gone ahead and made a page just for such community projects. Here you can make a page for your long-running project to provide documentation for people who might be interested in using it, coordinate with other developers who might want to work on it with you, and generally provide a hub for community interaction around new features/projects.Vacancy on the committee
As I mentioned in the pre-release blog for 3.6, Andrew has had to give up his seat on the Committee due to work commitments. We're still looking for a member to fill this seat, so if you're interested, or even curious about what the role would entail, shoot an email to myself (email is in my profile), one of the other Committee members, or David Wyand at GarageGames.We're looking for people who have a passion for improving the engine technology that allows others to make whatever they set their hearts to - it's really more about effort and willingness to participate than raw programming talent! We also welcome people of any skillset - artistic talent is a noted deficiency among the current committee members, and we wouldn't mind someone who's passionate about community development, publicity, etcetera!
So if you think you have something to offer and you want to see Torque become the open-source game engine of choice, then send us your details!
Acknowledgments
This release wouldn't have happened without the hard work of a lot of people. In alphabetical order, our repository contributors for this release are:- Kyrah Abattoir
- Azaezel
- Daniel Buckmaster
- Anders Dahnielson
- Jack Davidson
- Thomas Fischer
- Lukas Joergensen
- Andrew Mac
- Fyodor Osokin
- Jeff Raab
- Luis Anton Rebollo
- smally
- Timmy
- James Urquhart
Farewell
We hope you enjoy the new version!About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#22
Yeah, If your directx isn't up to date, I'd suggest starting with that.
As for the log, yes that's always helpful. Go ahead and throw it up on pastebin and toss us the link and we'll have a look.
10/09/2014 (6:12 pm)
Hey Scot,Yeah, If your directx isn't up to date, I'd suggest starting with that.
As for the log, yes that's always helpful. Go ahead and throw it up on pastebin and toss us the link and we'll have a look.
#23
Hey Scott, sorry to hear that. It's hard to diagnose that from here, but having a console.log would be handy. Do try installing DX9, and let us know how it goes!
10/09/2014 (6:13 pm)
EDIT: ninja'd.Hey Scott, sorry to hear that. It's hard to diagnose that from here, but having a console.log would be handy. Do try installing DX9, and let us know how it goes!
#24
http://www.garagegames.com/community/blogs/view/22838
I've had nothing but trouble compiling with it in the older code with 3.5 and now if that was added, I think it would be great to help us who don't know coding. Or would anyone be willing to add it to a branch where I could download the working EXE compiled from it? Let me know and good work guys.
10/09/2014 (6:18 pm)
Will we ever see this added to the branch of the T3D updates?http://www.garagegames.com/community/blogs/view/22838
I've had nothing but trouble compiling with it in the older code with 3.5 and now if that was added, I think it would be great to help us who don't know coding. Or would anyone be willing to add it to a branch where I could download the working EXE compiled from it? Let me know and good work guys.
#25
pastebin.com/smRA66B2
I really think we need an installer for mass appeal and user friendliness. A big download button on the main page would be nice too.
10/10/2014 (1:42 pm)
here's the log. It looks like a certain path is assumed. pastebin.com/smRA66B2
I really think we need an installer for mass appeal and user friendliness. A big download button on the main page would be nice too.
#26
10/10/2014 (2:14 pm)
Please no nasty installer? They are totally useless.
#27
10/10/2014 (3:21 pm)
Well, it's just one guy's opinion, but I think the average 15-25 year old male (those who are probably the most likely to be interested) typically have short attention spans. So, a big Download Here button and an easy installer that puts an icon on their desktop and opens the program to a cool starter level would go a long way toward being more user-friendly and gain a lot more people playing around with the engine. Just a thought. I've been working with it for several years, and while I'm not a programmer, I have a fairly good handle on it. Yet, I can't run the current demo out of the box. If I hadn't read the blog I wouldn't even know there was a new version or where to get it.
#28
Which main page do you mean for a big download button?
10/10/2014 (3:42 pm)
Scott, do you have any zip folders next to the engine exe? This looks a lot like a bug I've been able to trip by placing a zip of the template next to the template executable.Which main page do you mean for a big download button?
#29
Both pages would be ideal. If you could just get GG to let one of your committee members make basic edits to the main page for this type of thing it would sure be a big help. Those headlines about Deadstate on KickStarter etc are so old it makes it look like no one's here.
10/10/2014 (4:01 pm)
Yes, that was it! Thanks Daniel, I had the original zip file in the directory. I wondered why I was getting 2 of all 3 levels, thought maybe one was for 32 bit and one for 64...lolBoth pages would be ideal. If you could just get GG to let one of your committee members make basic edits to the main page for this type of thing it would sure be a big help. Those headlines about Deadstate on KickStarter etc are so old it makes it look like no one's here.
#30
10/10/2014 (5:27 pm)
Do you really think people who are not able to unzip a simple file will be able to use a game engine and code in C++ to build a real game?
#31
10/10/2014 (9:05 pm)
Well, it happened to me, so yes. It's also very confusing when it does happen, because the behavior is completely, utterly unexpected. It's quite easy to trigger if you unzip the zip in the same folder, because then the executable will be placed next to the original zip.
#32
10/11/2014 (4:25 am)
Hay dan you gotta get someone from GG to mention this on the GG news feed on their homepage. They always mention T2D releases.
#33
10/11/2014 (9:01 am)
Amazing work guys! Thanks a lot for the effort in keeping the community alive. AWESOME!
#34
The duplication happens because Torque treats zips as virtual folders. When it goes to run and does it's initialization, several scripts auto-parse and run, such as the various main.cs files. So when Torque is loading up, it sees a folder(that happens to be our zip) and parses through it and execs all those scripts a second time.
Naturally, this breaks a lot of stuff. So we'll need to implement a fix/sanity check on it to prevent it from doing that.
10/12/2014 (9:21 pm)
@ScotThe duplication happens because Torque treats zips as virtual folders. When it goes to run and does it's initialization, several scripts auto-parse and run, such as the various main.cs files. So when Torque is loading up, it sees a folder(that happens to be our zip) and parses through it and execs all those scripts a second time.
Naturally, this breaks a lot of stuff. So we'll need to implement a fix/sanity check on it to prevent it from doing that.
#35
Ok, I have thanked the steering committee and all of that but, as I dig into the 'new' code.....
WTF? I get it. Really I do, but explain to me how this '64' bit works? How can I take advantage of it? I am seeing a 'slight' increase in my FPS (Since I am a game artist... I can TOTALLY get behind anything that gives me more FPS)..... ok enough 'faking it'... LOL.
I understand why 64 bit is way cool and all the great work you all did. No kidding but, hey. If I was 'joe blow' coming into T3D for the first time... where is the docs? Where is the examples and the 'explanation' as to why 64 is better than 32 bit? Additionally, how do I as a first time developer take advantage of these (really cool), features?
Here is what led to this post.... I was thinking that 'hey, in the current T3D project I am working on.... I REALLY need Motion blur...!!).
I am an artist so I always think of the 'effects' first.
LOL, Uhm.... I giggle because my self and Dave W CREATED A FREAKIN MOTION BLUR back in 2.0..... HELL, I did not remember that and we did it as an ancient Steering committee.
Here is my ultimate point, we are CONSISTENTLY adding new and amazing features. This is good. Who the F*ck is making sure this new stuff is documented and who is making sure that anyone that knows about T3D is tracking HOW to use all this 'great new stuff?"
As a NON-programmer.... WTF does 64 bit mean to me?
Just a thought and point to explain where the hell I am coming from.
Ron
10/13/2014 (12:48 pm)
If you don't wanna read all this post.... here is the 'ultimate point'... Cool stuff... but, where the hell do we document all of this changes?Ok, I have thanked the steering committee and all of that but, as I dig into the 'new' code.....
WTF? I get it. Really I do, but explain to me how this '64' bit works? How can I take advantage of it? I am seeing a 'slight' increase in my FPS (Since I am a game artist... I can TOTALLY get behind anything that gives me more FPS)..... ok enough 'faking it'... LOL.
I understand why 64 bit is way cool and all the great work you all did. No kidding but, hey. If I was 'joe blow' coming into T3D for the first time... where is the docs? Where is the examples and the 'explanation' as to why 64 is better than 32 bit? Additionally, how do I as a first time developer take advantage of these (really cool), features?
Here is what led to this post.... I was thinking that 'hey, in the current T3D project I am working on.... I REALLY need Motion blur...!!).
I am an artist so I always think of the 'effects' first.
LOL, Uhm.... I giggle because my self and Dave W CREATED A FREAKIN MOTION BLUR back in 2.0..... HELL, I did not remember that and we did it as an ancient Steering committee.
Here is my ultimate point, we are CONSISTENTLY adding new and amazing features. This is good. Who the F*ck is making sure this new stuff is documented and who is making sure that anyone that knows about T3D is tracking HOW to use all this 'great new stuff?"
As a NON-programmer.... WTF does 64 bit mean to me?
Just a thought and point to explain where the hell I am coming from.
Ron
#36
Now if your post was about adding a norm for documenting all new features that gets included and not just features in general, then I'd be inclined to agree that we need some guidelines on that front. Just need to be careful not to scare developers away with regulations and stuff :)
10/13/2014 (3:03 pm)
@Ron, read the blog. We are currently working on improving documentation through the Wiki where we hope we will be able to document most of T3D. Ofc it will take time, as T3D is huge, but I hope we will get most of the areas covered over time.Now if your post was about adding a norm for documenting all new features that gets included and not just features in general, then I'd be inclined to agree that we need some guidelines on that front. Just need to be careful not to scare developers away with regulations and stuff :)
#37
As for 64 bit, we do need some way for new people to get into this and stuff like it. But anyway, that's the point of the wiki. Someone, quick, make a page explaining what 64-bit is!
EDIT: Ninja'd. But now that you mention it Lukas, it'd be good to have some kind of standard of documentation - like if you want a new feature added that you've written, please commit to at least making a skeleton wiki page with links to the source/examples for someone to fill in later.
10/13/2014 (3:19 pm)
I made you a page on the wiki :).As for 64 bit, we do need some way for new people to get into this and stuff like it. But anyway, that's the point of the wiki. Someone, quick, make a page explaining what 64-bit is!
EDIT: Ninja'd. But now that you mention it Lukas, it'd be good to have some kind of standard of documentation - like if you want a new feature added that you've written, please commit to at least making a skeleton wiki page with links to the source/examples for someone to fill in later.
#38
You are both right, I should step up, not 'complain' and serious commit to 'working the problems.' Thanks and I will see what I can do. Uhm, did not know we even had a functioning wiki, and you all know I have been around a bit :-)
Ron
10/13/2014 (4:40 pm)
Wow, ok thanks Lukas and Daniel.You are both right, I should step up, not 'complain' and serious commit to 'working the problems.' Thanks and I will see what I can do. Uhm, did not know we even had a functioning wiki, and you all know I have been around a bit :-)
Ron
#39
read this:
http://stackoverflow.com/questions/2378399/are-64-bit-programs-bigger-and-faster-than-32-bit-versions
10/14/2014 (8:03 pm)
@Ronread this:
http://stackoverflow.com/questions/2378399/are-64-bit-programs-bigger-and-faster-than-32-bit-versions
#40
Next week ... start working on 3.7 :D
10/15/2014 (1:45 am)
Thx to all people make this possible.Next week ... start working on 3.7 :D

Torque 3D Owner Scottie Sirius
EDIT: I got the desert level to run but the colors are all whacky. I wonder if I need dx9 installed directly. It's been a long time since I've ran a stock version.