DotNetTorque takes another turn and twist for the better!
by Vince Gee · 03/28/2012 (10:21 am) · 15 comments
Wow, what a crazy last two weeks!
On the terms on DotNetTorque, it is moving along. I have about 20 or so scripts left to convert over to cSharp. I guess I really did underestimate the amount of time it would take to convert all of the torqueScript (minus gui) over to cSharp. I am now down to just 20 files or so in the Core/Scripts/Client folder and I will be done with it.
I really do believe that I am the first person to ever read all the TorqueScript files inside of the starter.FPS example. I've found mistakes, oops, and some logic bugs sprinkled generously throughout the TorqueScript. I fixed the ones I could, and logged the remainder of them on our Team Foundation Server.
Performance measuring has been difficult because it is really hard to run comparisons between stock T3D and a wrapped T3D dll. When you run the analyzer against the C++ you get different results when compared to running the analyzer against CSharp. I am hoping to get some firm numbers soon, but really what does it mean?
I know the server is smooth; there are no hangs when spinning objects into view for the first time. No hangs when a player is logging in with another player inside the game. Bullets fly smoothly and fire without the visual rate increasing or decreasing as the amount of objects increase/decrease/etc.
I have also improved the linkage between C++ and CSharp so that after the engine is initialized, any and all reflections are kept to the bare minimum. That has shown to provide a significant performance gain. I know using reflections in CSharp is slow, but you never realize how slow it is until you remove it.
On a completely separate front,
At my day job here in D.C. we had two programming openings come up unexpected. Two of the guys on my team decided to head off into the sunset doing government contracts and leave the company. This, put me in a mad scramble to replace them.
So, I had a crazy idea. Here at Winterleaf, I have two guys that have been programming with me for the last 2 years since we started this project. I knew their work ethics, how good they could program, and well their personalities, etc. In fact I had met them both in face over the last two years. So I floated the two openings to them.
The first guy lived in Oklahoma, and the other guy in Georgia. It would require them to drop everything, pack and move to here in Maryland. Mind you, I did offer them significant increases in pay over their current jobs.
The way I figured it, if we all lived here in Maryland we could get even more work done on the Winterleaf stuff and I would gain a solid team working for me at work. So, I asked.
Long story short, sometimes it does pay to join up with a project here on Garagegames. Those two guys got new sweet jobs at a Brick and Mortar fortune 500 company programming, Winterleaf got centralized in Maryland, and I got two crack programmers to work for me at the office.
Life is good.....
p.s.: Gonna miss the end of month beta, just too buried in too many directions at the moment, but I will be done soon.
Vince
On the terms on DotNetTorque, it is moving along. I have about 20 or so scripts left to convert over to cSharp. I guess I really did underestimate the amount of time it would take to convert all of the torqueScript (minus gui) over to cSharp. I am now down to just 20 files or so in the Core/Scripts/Client folder and I will be done with it.
I really do believe that I am the first person to ever read all the TorqueScript files inside of the starter.FPS example. I've found mistakes, oops, and some logic bugs sprinkled generously throughout the TorqueScript. I fixed the ones I could, and logged the remainder of them on our Team Foundation Server.
Performance measuring has been difficult because it is really hard to run comparisons between stock T3D and a wrapped T3D dll. When you run the analyzer against the C++ you get different results when compared to running the analyzer against CSharp. I am hoping to get some firm numbers soon, but really what does it mean?
I know the server is smooth; there are no hangs when spinning objects into view for the first time. No hangs when a player is logging in with another player inside the game. Bullets fly smoothly and fire without the visual rate increasing or decreasing as the amount of objects increase/decrease/etc.
I have also improved the linkage between C++ and CSharp so that after the engine is initialized, any and all reflections are kept to the bare minimum. That has shown to provide a significant performance gain. I know using reflections in CSharp is slow, but you never realize how slow it is until you remove it.
On a completely separate front,
At my day job here in D.C. we had two programming openings come up unexpected. Two of the guys on my team decided to head off into the sunset doing government contracts and leave the company. This, put me in a mad scramble to replace them.
So, I had a crazy idea. Here at Winterleaf, I have two guys that have been programming with me for the last 2 years since we started this project. I knew their work ethics, how good they could program, and well their personalities, etc. In fact I had met them both in face over the last two years. So I floated the two openings to them.
The first guy lived in Oklahoma, and the other guy in Georgia. It would require them to drop everything, pack and move to here in Maryland. Mind you, I did offer them significant increases in pay over their current jobs.
The way I figured it, if we all lived here in Maryland we could get even more work done on the Winterleaf stuff and I would gain a solid team working for me at work. So, I asked.
Long story short, sometimes it does pay to join up with a project here on Garagegames. Those two guys got new sweet jobs at a Brick and Mortar fortune 500 company programming, Winterleaf got centralized in Maryland, and I got two crack programmers to work for me at the office.
Life is good.....
p.s.: Gonna miss the end of month beta, just too buried in too many directions at the moment, but I will be done soon.
Vince
About the author
www.winterleafentertainment.com
#2
There REALLY is a lot of scripts in the starter.fps that you take for granted since you rarely need to modify them.... really... ALOT...
LOL
03/28/2012 (7:42 pm)
ooo...... look... more scripts.... sigh, I swear I burn through 5-8 scripts a night and the pile doesn't seem to go down very fast. I really need to outsource some of this work...There REALLY is a lot of scripts in the starter.fps that you take for granted since you rarely need to modify them.... really... ALOT...
LOL
#3
Honestly, I cant wait to have the 3 of us in Maryland. Itll be nice to be living that close.
besides some of the C# programmers that Vince wants, we still need 1 or 2 more C++ programmers that wants a project that they can believe in - and are at least partially insane. Youll need to be once you hear what the ideas are *smile*
We figure we will put out an official "looking for" once DotNetTorque goes BETA, but hey unofficially.....
03/28/2012 (9:46 pm)
yeah yeah..... I got as far as Marshal, Ill today.... Ill drive the rest of the way to Maryland tomorrow :pHonestly, I cant wait to have the 3 of us in Maryland. Itll be nice to be living that close.
besides some of the C# programmers that Vince wants, we still need 1 or 2 more C++ programmers that wants a project that they can believe in - and are at least partially insane. Youll need to be once you hear what the ideas are *smile*
We figure we will put out an official "looking for" once DotNetTorque goes BETA, but hey unofficially.....
#4
John K.
03/28/2012 (10:33 pm)
Vince, what are the release plans for DotNetTorque? Is this a community project, a resource, or a product that will be sold in the GarageGames store? Given that C# is my favorite language that exists, I'm very eager to try this out. John K.
#5
It will be a product offered on the GG website. I'm not sure what we will be charging, but it will most likely be priced the same line of AFX. Included in the product will be a the 2 C++ include files to convert any stock T3D build to be cSharp enabled and the FPS example converted to cSharp.
I know the price might seem steep, but my team has hundred of hours designing the solution and converting the starter.fps.
The beauty of the solution is that you can run a hybrid project where some of the code is TorqueScript and some of it is CSharp, etc. So if you have an existing project and only want to convert the most time consuming functions to cSharp, you can do it. If you are starting from scratch you will be able to use our Starter.Fps and ripe out what you don't want.
I am trying to keep the code line for line to the TorqueScript. So, if you are learning the CSharp design, you can follow line by line against the TorqueScript.
Is the design of the starter.fps the way I would implement a game?... no, it is meant as a starting point for people using the libraries I wrote to interact with the T3D dll.
Ironically, the cSharp code is a great lesson in Marshaling in CSharp. I found that even though there is a good bit of example code on the Internet for CSharp Marshalling, their is in actuality very little code out there that is written so that someone unfamiliar with Marshalling can understand.
So you will be getting far more just a CSharp port, you will get a lessons in LINQ, Marshaling, Extensions and much more. I try to keep the code straight forward, but as optimized as possible for performance.
Where are we going with this?
Well, this code base is the first step to building a SMOG, (Small Multiplayer Online Game). (Think I just coined a new abbrev) After finishing the Starter.FPS, we will be splitting the client and server into separate builds and start a serious optimization of design.
While the above is going on, another person on the team will be ripping out all the interface code inside of Torque and begin swapping it out with WPF DX9 injection. So on the client, we will be able to use WPF instead of the stock Torque Gui stuff.
Our goal is to simplify T3D into just a presentation layer for the client. Where all the meat of the game logic and interface is implemented in CSharp and Torque just handles the rendering.
On the server side, our goal is to strip the server down to the point where we are using it just for client coordination and physics, with all the business logic, database stuff, etc is implemented in CSharp.
Once the above is finished, we then plan to release our SMOG as a new product so that anyone wishing to build a SMOG will have all the foundation needed to get started.
....
On a completely separate effort, we have artists now building SMOG optimized artwork, models, etc which we also plan to sell via GG. This artwork will be designed for the MMO Genre leveraging Mesh Hiding, LOD's Textures, bump maps, etc. to reduce the poly count down as far as we can while still providing high quality art.
Finally, we are hoping that as we do this, GarageGames themselves will take a serious look at their engine and firm up all the S32/U32 inconsistencies in the way the reference objects in the engine as well as other little annoyances so that the engine is ready for prime time when we release. In the event that GarageGames isn't able to get everything it done, a seperate project will be fired off to perform the cleanup inside of Winterleaf.
If time and money allows (We hope to sell a lot of this build) we plan to take all the money earned through selling our artwork, DotNetTorque, Patcher, and any other product we build to be pumped into a project to take T3D to a 64bit architecture.
Since all of the founders of Winterleaf do have day jobs, the money made through selling our products will be used to pay our Artists (#1, since for some reason they are all starving), then #2, hire C++ programmers to really pull the lid off the Torque engine and fix things that have been pissing me off while doing this conversion.
Well, that is our plan in a nutshell, if you want more details, you have to talk to Paul, he's the ringleader of this circus.
Vince
03/29/2012 (4:55 am)
John,It will be a product offered on the GG website. I'm not sure what we will be charging, but it will most likely be priced the same line of AFX. Included in the product will be a the 2 C++ include files to convert any stock T3D build to be cSharp enabled and the FPS example converted to cSharp.
I know the price might seem steep, but my team has hundred of hours designing the solution and converting the starter.fps.
The beauty of the solution is that you can run a hybrid project where some of the code is TorqueScript and some of it is CSharp, etc. So if you have an existing project and only want to convert the most time consuming functions to cSharp, you can do it. If you are starting from scratch you will be able to use our Starter.Fps and ripe out what you don't want.
I am trying to keep the code line for line to the TorqueScript. So, if you are learning the CSharp design, you can follow line by line against the TorqueScript.
Is the design of the starter.fps the way I would implement a game?... no, it is meant as a starting point for people using the libraries I wrote to interact with the T3D dll.
Ironically, the cSharp code is a great lesson in Marshaling in CSharp. I found that even though there is a good bit of example code on the Internet for CSharp Marshalling, their is in actuality very little code out there that is written so that someone unfamiliar with Marshalling can understand.
So you will be getting far more just a CSharp port, you will get a lessons in LINQ, Marshaling, Extensions and much more. I try to keep the code straight forward, but as optimized as possible for performance.
Where are we going with this?
Well, this code base is the first step to building a SMOG, (Small Multiplayer Online Game). (Think I just coined a new abbrev) After finishing the Starter.FPS, we will be splitting the client and server into separate builds and start a serious optimization of design.
While the above is going on, another person on the team will be ripping out all the interface code inside of Torque and begin swapping it out with WPF DX9 injection. So on the client, we will be able to use WPF instead of the stock Torque Gui stuff.
Our goal is to simplify T3D into just a presentation layer for the client. Where all the meat of the game logic and interface is implemented in CSharp and Torque just handles the rendering.
On the server side, our goal is to strip the server down to the point where we are using it just for client coordination and physics, with all the business logic, database stuff, etc is implemented in CSharp.
Once the above is finished, we then plan to release our SMOG as a new product so that anyone wishing to build a SMOG will have all the foundation needed to get started.
....
On a completely separate effort, we have artists now building SMOG optimized artwork, models, etc which we also plan to sell via GG. This artwork will be designed for the MMO Genre leveraging Mesh Hiding, LOD's Textures, bump maps, etc. to reduce the poly count down as far as we can while still providing high quality art.
Finally, we are hoping that as we do this, GarageGames themselves will take a serious look at their engine and firm up all the S32/U32 inconsistencies in the way the reference objects in the engine as well as other little annoyances so that the engine is ready for prime time when we release. In the event that GarageGames isn't able to get everything it done, a seperate project will be fired off to perform the cleanup inside of Winterleaf.
If time and money allows (We hope to sell a lot of this build) we plan to take all the money earned through selling our artwork, DotNetTorque, Patcher, and any other product we build to be pumped into a project to take T3D to a 64bit architecture.
Since all of the founders of Winterleaf do have day jobs, the money made through selling our products will be used to pay our Artists (#1, since for some reason they are all starving), then #2, hire C++ programmers to really pull the lid off the Torque engine and fix things that have been pissing me off while doing this conversion.
Well, that is our plan in a nutshell, if you want more details, you have to talk to Paul, he's the ringleader of this circus.
Vince
#6
However, Vince is right on almost all of this. DotNetTorque and our updater program is what we are hoping to build everything off of. DotNetTorque will allow people who are wanting to create a FPS to make one in C# and have an EXTREMELY optimized engine to work with. That being said, this is also the prime building block of the OMNI Development Suite - the MMO development Suite that we are designing. The updater program that Rich is writing will be our hook for the updater/login server. You will see this in action when we put DotNet Torque out for BETA.
The GUI side will take the normally static UI and make it into a more "modern" MMO GUI feel. For anyone that has played a MMO, they will understand exactly what im saying.
Not to leave them out, Tim and Bobby, our Art Team, is second to none. They have been doing some MASSIVE work on the art side to handle the low poly art necessary for a MMO. The art work and design that they have done on both buildings and characters are incredible. They are still looking to finish our first male and female models (human) but according to Tim, he should have a video and blog out the in the next
few weeks.
As far as the Torque engine itself goes, and cleaning it up and making it 64bit - remember that comment made earlier about "insane C++ programmers"? run with that.
The ONLY statement that Vince made that I would argue with is the SMOG. I believe that by the time that we are done with this, we will be able to handle a MMO scenario. Ive seen what our design can handle so far, and what it was handling PRIOR TO the rewrites. Our MMO design - prior to the C# rewrite - was about to handle OVER 300 active AIs in a "zone". I cant wait to see what this will handle now. Yes, im well aware players and AIs are different, but that shows that our design will work.
So, ill say again, if you are interested, like what youve read, and are more than than a little nuts, drop me a line at pyoskowitz(AT)winterleafentertainment(DOT)com. it takes more than just C# and C++ programmers, so if youre interested and thats NOT for forte, drop me a line anyways.
03/29/2012 (5:52 am)
And here I was, reading all this goin, "man, awesome blog Vince!" and SUDDENLY i get tossed under the bus. Dude.....However, Vince is right on almost all of this. DotNetTorque and our updater program is what we are hoping to build everything off of. DotNetTorque will allow people who are wanting to create a FPS to make one in C# and have an EXTREMELY optimized engine to work with. That being said, this is also the prime building block of the OMNI Development Suite - the MMO development Suite that we are designing. The updater program that Rich is writing will be our hook for the updater/login server. You will see this in action when we put DotNet Torque out for BETA.
The GUI side will take the normally static UI and make it into a more "modern" MMO GUI feel. For anyone that has played a MMO, they will understand exactly what im saying.
Not to leave them out, Tim and Bobby, our Art Team, is second to none. They have been doing some MASSIVE work on the art side to handle the low poly art necessary for a MMO. The art work and design that they have done on both buildings and characters are incredible. They are still looking to finish our first male and female models (human) but according to Tim, he should have a video and blog out the in the next
few weeks.
As far as the Torque engine itself goes, and cleaning it up and making it 64bit - remember that comment made earlier about "insane C++ programmers"? run with that.
The ONLY statement that Vince made that I would argue with is the SMOG. I believe that by the time that we are done with this, we will be able to handle a MMO scenario. Ive seen what our design can handle so far, and what it was handling PRIOR TO the rewrites. Our MMO design - prior to the C# rewrite - was about to handle OVER 300 active AIs in a "zone". I cant wait to see what this will handle now. Yes, im well aware players and AIs are different, but that shows that our design will work.
So, ill say again, if you are interested, like what youve read, and are more than than a little nuts, drop me a line at pyoskowitz(AT)winterleafentertainment(DOT)com. it takes more than just C# and C++ programmers, so if youre interested and thats NOT for forte, drop me a line anyways.
#7
John K.
03/29/2012 (9:03 am)
Thank you Vince and Paul, this sounds like a great solution. I'm looking forward to purchasing this and get back to 3D game development with C#. Will I be able to use VS2010 for coding, complete with syntax highlighting and intellisense? It would be nice to keep all C++ & C# coding within one editor. In any case, if there's a Beta coming soon, I'm interested in participating.John K.
#8
I've grouped the externs by their object types, so GameConnection has a collection of functions, gui's etc, and since you get all the source code, it will be easy to find these functions. (Usually I do a ctrl-alt-f on the console function name and see if any externs show)
One really nice feature is that you can not only do your development in visual studio 2010, but you can also debug your scripts in it too! AND you can use immediates to query the torque engine while debugging.
I also use the AMD analyzers against it and see what script functions are taking the longest to run etc. It really is putting the T3D engine on steriods in both terms of development speed and performance.
vince
03/29/2012 (9:39 am)
Yes, one thing I made sure of was that there was some sort of intellisense in the code. So, as long as you know what type of TorqueObject you are working with, i.e. shapebase, then you can type something like ShapeBase.SetName(ID,string name) and you will be told what the parameters are via intellesense. (I actually found functions that I didn't know existed until I did the conversion.)I've grouped the externs by their object types, so GameConnection has a collection of functions, gui's etc, and since you get all the source code, it will be easy to find these functions. (Usually I do a ctrl-alt-f on the console function name and see if any externs show)
One really nice feature is that you can not only do your development in visual studio 2010, but you can also debug your scripts in it too! AND you can use immediates to query the torque engine while debugging.
I also use the AMD analyzers against it and see what script functions are taking the longest to run etc. It really is putting the T3D engine on steriods in both terms of development speed and performance.
vince
#9
We will be having two beta's. One beta is where people will be able to download our client and connect to our server to see the performance first hand. (Also, to test how sold our server build is)
The second beta, will be a source code beta where we plan to select a few seasoned T3D developers who are familiar with T3D and cSharp to actually play with the source code, find bugs, etc.
Part of the source code beta requirements is that you will need to blog the good/bad/ugly of the product on GarageGames. Our NDA will be very liberal, mainly just requiring that the code behind the extern's and core code not be released.
The first beta should be this month, and the source beta will most likely be next month, since even after I'm done coding the starter.fps, the documentation needs to be generated. (Thankfully, that is not my job.... Paul?....)
So anyone interested in getting into the source code beta, should probally start contacting Paul now to get all the paperwork and stuff in order. And in case you missed it, his email is
..... here comes the bus again....
He loves reading email, so make sure you list your experience with csharp and torque in the email.
Vince
03/29/2012 (9:48 am)
Almost forgot,We will be having two beta's. One beta is where people will be able to download our client and connect to our server to see the performance first hand. (Also, to test how sold our server build is)
The second beta, will be a source code beta where we plan to select a few seasoned T3D developers who are familiar with T3D and cSharp to actually play with the source code, find bugs, etc.
Part of the source code beta requirements is that you will need to blog the good/bad/ugly of the product on GarageGames. Our NDA will be very liberal, mainly just requiring that the code behind the extern's and core code not be released.
The first beta should be this month, and the source beta will most likely be next month, since even after I'm done coding the starter.fps, the documentation needs to be generated. (Thankfully, that is not my job.... Paul?....)
So anyone interested in getting into the source code beta, should probally start contacting Paul now to get all the paperwork and stuff in order. And in case you missed it, his email is
..... here comes the bus again....
pyoskowitz(AT)winterleafentertainment(DOT)com
He loves reading email, so make sure you list your experience with csharp and torque in the email.
Vince
#10
What will happen is that when the INITAL BETA starts, we will have the WLE forums up and running. There will be a place to put your bug reports, gripes, Vince Gee jokes, etc. once that BETA is completed and the bugs worked out, we are hoping to start the code BETA *AS LONG AS* there are no OMG over the top bugs found in the original BETA. Now, we haven't decided if we were goin to allow people to keep blowing each other up or close down the FPS BETA yet. Kinda depends on how many people want to keep shooting each other.
As far as the code BETA goes, we are still discussing what (and to whom) will be released in the BETA version.
03/29/2012 (9:25 pm)
I cant WAIT to start writing bug reports for you Vince.....What will happen is that when the INITAL BETA starts, we will have the WLE forums up and running. There will be a place to put your bug reports, gripes, Vince Gee jokes, etc. once that BETA is completed and the bugs worked out, we are hoping to start the code BETA *AS LONG AS* there are no OMG over the top bugs found in the original BETA. Now, we haven't decided if we were goin to allow people to keep blowing each other up or close down the FPS BETA yet. Kinda depends on how many people want to keep shooting each other.
As far as the code BETA goes, we are still discussing what (and to whom) will be released in the BETA version.
#11
No big misteries, no terrible fears of past unacomplished goals, no doubt or hesitation about direction... Isnt this a perfectly transparent yet totally under control company roadmap?
I only wish the engine development itself be this clear and to the point!
Thanks Vince and Paul for leting us see how you guys get things done (and in such a way!)
Excellent ideas, and excellent execution. Cheers for you guys!
03/30/2012 (7:03 pm)
Jesus, Mary and Joseph.No big misteries, no terrible fears of past unacomplished goals, no doubt or hesitation about direction... Isnt this a perfectly transparent yet totally under control company roadmap?
I only wish the engine development itself be this clear and to the point!
Thanks Vince and Paul for leting us see how you guys get things done (and in such a way!)
Excellent ideas, and excellent execution. Cheers for you guys!
#12
Thats exactly how i like to think that we run this group. everyone is kept pretty much in the loop, not alot is hidden (if anything) and every has a say of some sort or another. It helps when everyone BELIEVES in our project as well. I think in some ways thats helped us more than offering a paycheck. dont get me wrong, ill be THRILLED the day i can hand out a few bucks to people and say "congrats, its finally paying off" but until then, we have a dedicated group of people that seem to get along reasonably most of the time and have few laughs along the way. i cant tell you how grateful i am for that because i interact with MOST of the people involved in this group at least once a day.. every other day at the longest i believe. sometimes its nothing more than a "hey, hows it goin" but its something. i dont think anyone involved with our project doubts that anyone else involved wont give this 110% of thier effort.
that feeling right there Novack, allows Vince and I to speak about this the way we do. totally open with everyone with what the goals are, and the expectations that we have for ourselves. We already missed a deadline - we were supposed to have a BETA out this weekend. life happens and we explained whats been happening and we've been keeping the lines of communication open between us and everyone else. We hope that, right there, will earn us some amount of respect with the GG community since we arent hiding off in the dark. I hate it when people keep me in the dark, esp about a product that Im waiting on, so why would i do that to others? I keep myself available to the WLE team and pretty much anyone thats part of the GG commnunity that would like to ask questions about WLE.
How much more transparent can i make us?
03/30/2012 (10:55 pm)
@Novack - thank you for the kind words. Funny enough, that means alot to hear something like that. Thats exactly how i like to think that we run this group. everyone is kept pretty much in the loop, not alot is hidden (if anything) and every has a say of some sort or another. It helps when everyone BELIEVES in our project as well. I think in some ways thats helped us more than offering a paycheck. dont get me wrong, ill be THRILLED the day i can hand out a few bucks to people and say "congrats, its finally paying off" but until then, we have a dedicated group of people that seem to get along reasonably most of the time and have few laughs along the way. i cant tell you how grateful i am for that because i interact with MOST of the people involved in this group at least once a day.. every other day at the longest i believe. sometimes its nothing more than a "hey, hows it goin" but its something. i dont think anyone involved with our project doubts that anyone else involved wont give this 110% of thier effort.
that feeling right there Novack, allows Vince and I to speak about this the way we do. totally open with everyone with what the goals are, and the expectations that we have for ourselves. We already missed a deadline - we were supposed to have a BETA out this weekend. life happens and we explained whats been happening and we've been keeping the lines of communication open between us and everyone else. We hope that, right there, will earn us some amount of respect with the GG community since we arent hiding off in the dark. I hate it when people keep me in the dark, esp about a product that Im waiting on, so why would i do that to others? I keep myself available to the WLE team and pretty much anyone thats part of the GG commnunity that would like to ask questions about WLE.
How much more transparent can i make us?
#13
Reading of the T3D code is easily understandable that the T3D was born to be compatible with XBox and PS3 (Although time has lost all OpenGL compatibility).
04/05/2012 (4:46 pm)
It seems a really great job. But have you thought about portability?Reading of the T3D code is easily understandable that the T3D was born to be compatible with XBox and PS3 (Although time has lost all OpenGL compatibility).
Torque Owner David Robert Pemberton
www.deadlyassets.com