Getting Torque 3D client to build on Linux
by Anders Dahnielson · 06/25/2013 (1:29 pm) · 11 comments
Just a couple of days ago I discovered that code to get Linux support for the client back into Torque 3D already exist. Support to build Torque 3D as a dedicated server on Linux is already present. But what I was interested in was to get the client, the bits that recieve input from the player and render the game world on screen, to work. So I decided to take a stab at trying to get the code to build and hopefully run. Because Linux is my choice of OS and I want Torque to run on it. At least on my box.
tl;dr
I wanted to see what it would take to get the current development branch of Torque 3D to build on Linux. It wasn't that hard.
What I did
I started off by forking the GarageGames/Torque3D repository at GitHub and then turned my attention to the linux-rnd branch that contain code from the Linux R&D that got me interested in the first place. However the code did not build. So I went through the code and incorporated the changes that had been made to the master branch (to get the dedicated server to build) but not the linux-rnd branch, in addition to some missing code for OpenAL support on Linux that I found in TheDushan/Torque3D repository. And with that I got the linux-rnd branch to build! Next I decided to try merge the reinstated Linux support with the current development branch. Which succeded and resulted in the linux-development branch that I pushed to my dahnielson/Torque3D repository.
What works
It compiles! It links! It runs! (Well, sort of.)
What doesn't
First, there is still not any support to generate projects to build the Linux client using the project generator included with Torque. As I have set up all projects necessary to build Torque manually in Code::Blocks.
Next, Torque3D will segfault when rendering a scene with lights as LightInfo::getType will try to return the Type of a null pointer cast as a LightInfo object, according to the debuger:
Also, keyboard input doesn't work completely.
Conclusion
Hopefully this means that full support for Linux would not be that far off into the future. Guess most work will be needed in the OpenGL rendering pipeline.
2013-06-27 - Updated
tl;dr
I wanted to see what it would take to get the current development branch of Torque 3D to build on Linux. It wasn't that hard.
What I did
I started off by forking the GarageGames/Torque3D repository at GitHub and then turned my attention to the linux-rnd branch that contain code from the Linux R&D that got me interested in the first place. However the code did not build. So I went through the code and incorporated the changes that had been made to the master branch (to get the dedicated server to build) but not the linux-rnd branch, in addition to some missing code for OpenAL support on Linux that I found in TheDushan/Torque3D repository. And with that I got the linux-rnd branch to build! Next I decided to try merge the reinstated Linux support with the current development branch. Which succeded and resulted in the linux-development branch that I pushed to my dahnielson/Torque3D repository.
What works
It compiles! It links! It runs! (Well, sort of.)
What doesn't
First, there is still not any support to generate projects to build the Linux client using the project generator included with Torque. As I have set up all projects necessary to build Torque manually in Code::Blocks.
Next, Torque3D will segfault when rendering a scene with lights as LightInfo::getType will try to return the Type of a null pointer cast as a LightInfo object, according to the debuger:
0x084a7c74 in LightInfo::getType (this=0x0) at ../../../../Engine/source/lighting/lightInfo.h:160
160 Type getType() const { return mType; }A quick and dirty work-around, just to get the mission to load, is to add a guard for line 244 in Engine/source/materials/processedFFMaterial.cpp:if ( sgData.lights[1] ) _setSecondaryLightInfo(*sgData.objTrans, sgData.lights[1]);
Also, keyboard input doesn't work completely.
Conclusion
Hopefully this means that full support for Linux would not be that far off into the future. Guess most work will be needed in the OpenGL rendering pipeline.
2013-06-27 - Updated
About the author
Bought his Torque Game Engine license in April 2004 and then pursued to not make very much with it.
#2
Not disappointed at all. This was just a personal experiment to see what it would take to get the current development branch of Torque 3D to build on Linux.
06/25/2013 (2:08 pm)
Glad to hear that there's active work going on! Not disappointed at all. This was just a personal experiment to see what it would take to get the current development branch of Torque 3D to build on Linux.
#3
06/25/2013 (11:09 pm)
Awesome to hear how close this is to happening. I'm pretty sure the LightInfo issue is a long-standing bug on GitHub that nobody's really sure what to do about. Yeah, here it is - maybe you can recommend a solution? 
#4
anybody have idea how and which compiler to use for building t3d's apk file for android?
once this is done then i will start to work on gfx part.
" As I have set up all projects necessary to build Torque manually in Code::Blocks."
can we use same Code::Blocks configuration to build t3d on windows?
06/26/2013 (9:55 am)
not interested on desktop linux but eagerly waiting to jump into developing android version. anybody have idea how and which compiler to use for building t3d's apk file for android?
once this is done then i will start to work on gfx part.
" As I have set up all projects necessary to build Torque manually in Code::Blocks."
can we use same Code::Blocks configuration to build t3d on windows?
#5
06/27/2013 (6:02 am)
You use the official Android SDK and NDK. I am the one porting T2D to android. I will be using the NDK as much as possible to keep from writing any java code. They have what is called a NativeActivity where you can setup the app in C++.
#6
@Daniel Buckmaster: I am not sure they're related as _setSecondaryLightInfo is called explicitly with sgData.lights[1] which is null. But I haven't yet had time to track down why it is null, or where it comes from, as I'm not yet that familiar with the current engine code.
@ahsan: I guess you can use Code::Blocks to build Torque on Windows. But it's not that hard to set up a project in Code::Blocks yourself. To get an idea of how it should build, take a look at the solutions generated by the project generator for other build systems.
@Tim Newell: Hopefully the the work on porting T2D to Android can benefit T3D further down the road? Because I would be excited about being able to deploy T2D aswell as T3D to Android. I'm playing just as much games on my Nexus 7 as I do on my desktop (and also need an excuse to get an Ouya).
06/27/2013 (8:15 am)
@J0linar: Do you know perhaps when Dushans port will be available? I wouldn't mind testing it as I'm quite anxious to be developing on Linux.@Daniel Buckmaster: I am not sure they're related as _setSecondaryLightInfo is called explicitly with sgData.lights[1] which is null. But I haven't yet had time to track down why it is null, or where it comes from, as I'm not yet that familiar with the current engine code.
@ahsan: I guess you can use Code::Blocks to build Torque on Windows. But it's not that hard to set up a project in Code::Blocks yourself. To get an idea of how it should build, take a look at the solutions generated by the project generator for other build systems.
@Tim Newell: Hopefully the the work on porting T2D to Android can benefit T3D further down the road? Because I would be excited about being able to deploy T2D aswell as T3D to Android. I'm playing just as much games on my Nexus 7 as I do on my desktop (and also need an excuse to get an Ouya).
#7
06/27/2013 (8:31 am)
@Anders Dahnielson: The platform and audio code (Android uses OpenSL ES instead of OpenAL) would probably be portable. Big thing missing in T3D right now is OpenGL ES 2.0 support since there is no iOS implementation. The opengl code in T2D is OpenGL ES 1.1 since T2D does not support shaders so it won't be a direct port over. I just got my Ouya in the mail, even though its not part of the android thing we are doing, I will probably get T2D working on it anyway when I have time. 
#8
the port is almost around the corner
i would suggest that you keep working on the linux side
just 1 thing don`t try to reinvent the wheel
what we currently would need when it comes to fixing would be the input on linux
it`s still not working like it should
so that would be one thing
@ahsan
linux is the bridge to android
and not being interested in linux is really a facepalm
same goes for
@Max Gaming
instead of just blindly tryin to get t2d on android
close the gap and get the linux side properly done
then move on to android
note: this is my personal oppinion
as evryone has it`s own ;)
06/28/2013 (3:33 am)
@Anders Dahnielsonthe port is almost around the corner
i would suggest that you keep working on the linux side
just 1 thing don`t try to reinvent the wheel
what we currently would need when it comes to fixing would be the input on linux
it`s still not working like it should
so that would be one thing
@ahsan
linux is the bridge to android
and not being interested in linux is really a facepalm
same goes for
@Max Gaming
instead of just blindly tryin to get t2d on android
close the gap and get the linux side properly done
then move on to android
note: this is my personal oppinion
as evryone has it`s own ;)
#9
@Anyone If anyone would like to help with the Linux port just let me know. It will still be a couple of months before I can get started on it but someone else can go ahead and start working on it now and I can help finish it up.
06/28/2013 (8:17 am)
@J0linar: We are not blindly porting it as we have done ports for contract before. We are being paid to port T2D to Android but not paid to port Linux so that is the main reason we are doing it. The secondary and just as important reason is we want to see T2D flourish and Android is more important than Linux right now. Once we are done with the Android port, depending on my time, I will port to Linux if no one else has done so yet. @Anyone If anyone would like to help with the Linux port just let me know. It will still be a couple of months before I can get started on it but someone else can go ahead and start working on it now and I can help finish it up.
#10
and worked already in that sector
appologiziesss for sayin you would be blindly porting
it`s just i don´t see the logic in the whole approach
note, am working mainly with T3D and
see problem is
the times we are in atm
look around and you will see that there are plenty engines that are focusing on multiplatform deployment
and yes actually almost all of those are commercial engines
now the situation we got here is a splitted community
when i say splitted - look at t2d and t3d mit
and what actually happend since both went mit
instead of getting those 2 engines closer
we are moving away with both
and instead of combining efforts
we are again breakin bridges here
so what i ask myself is
why do we have todo this?
for the succes of a single product for selfpromotion?
the steering commitees along with some community members
could gather around a table (aye where is mY eXcalibuuur)
and work out a so called end solution
that would path the way for not just linux/android but more...
agreed this would mean that there wouldn`t be a update regarding both engines
at least for a couple of months but the win would be t2d/t3d - multiplatform support and not just linux for t3d or android for t2d
anyways i know this is unlikely to happen
evryone here has its own idea of how the stone should roll
but there aren´t many who share the same idea
only time will tell what will really happen and yes i might be even wrong with all of this.
06/28/2013 (8:47 am)
k true - Maxgaming did contract workand worked already in that sector
appologiziesss for sayin you would be blindly porting
it`s just i don´t see the logic in the whole approach
note, am working mainly with T3D and
see problem is
the times we are in atm
look around and you will see that there are plenty engines that are focusing on multiplatform deployment
and yes actually almost all of those are commercial engines
now the situation we got here is a splitted community
when i say splitted - look at t2d and t3d mit
and what actually happend since both went mit
instead of getting those 2 engines closer
we are moving away with both
and instead of combining efforts
we are again breakin bridges here
so what i ask myself is
why do we have todo this?
for the succes of a single product for selfpromotion?
the steering commitees along with some community members
could gather around a table (aye where is mY eXcalibuuur)
and work out a so called end solution
that would path the way for not just linux/android but more...
agreed this would mean that there wouldn`t be a update regarding both engines
at least for a couple of months but the win would be t2d/t3d - multiplatform support and not just linux for t3d or android for t2d
anyways i know this is unlikely to happen
evryone here has its own idea of how the stone should roll
but there aren´t many who share the same idea
only time will tell what will really happen and yes i might be even wrong with all of this.
#11
06/28/2013 (9:48 am)
I apologize if I sounded angry about your comment, I did not mean to :) I do agree it would be nice to have both engines following the same path, T2D has had a lot of nice cleanup and the inner workings of T3D are still muddy. I still think a project to take T2D and integrate the good parts of T3D into it to make a new 3d engine would be cool, but a ton of work. 
J0linar
now this might dissapoint you a bit
but there has been some work recentlly
regarding
Dushans port and he is currently makin it suitable for the T3D Mit Version
so that it can be eventually included in the upcoming release of T3D v4
however you shouldn`t just skip what you did
am glad there are more ppl wanting to use and have T3D runnin on Lunix
so maybe you want to join the cause?
www.garagegames.com/community/blogs/view/22330
and contribute something/ take over where others left?
up to you