Definitive Resource for TBE and Eclipse in demand
by Andy Hawkins · in Torque Game Engine · 08/15/2005 (6:24 pm) · 25 replies
I've been trying to write a tute to help out people getting Torque to compile using the TBE and Eclipse IDE suite of tools. So far it's way too complicated for people to understand. I can get Torque compiling in Vis Studio 6 but Eclipse is failing at mainly using the vorbis code, mainly concerned with be unable to link codec.h. But there's other stuff as well for example the main resource if you follow the instruction "no-brainer" solution doesn't work "out of the box". There's even hacks to the config file which most people would have problems with.
Can someone provide clear information of fixing these issues with vorbis and other things involved with getting TBE running - email me if you want so I can consolidate all this info.
In doing so I think we need a dedicated resource purely to getting TBE and Eclipse to compile. It should not be just, click on this forum to resolve this issue, and then try this, and then try this... because I've been running around in circles doing this, ending up in old resources and mixed information.
To the newer user this is way too complicated.
The structure of the Resource should be like this...
a) Where to get all the stuff
b) How to configure it - even providing make file and config changes so the user doesn't have to hack anything.
c) Support for Linux, Max and Win32
d) Link to a new forum to iron out any issues.
I believe an almost "one-click" solution can be provided if we get it right.
Can someone provide clear information of fixing these issues with vorbis and other things involved with getting TBE running - email me if you want so I can consolidate all this info.
In doing so I think we need a dedicated resource purely to getting TBE and Eclipse to compile. It should not be just, click on this forum to resolve this issue, and then try this, and then try this... because I've been running around in circles doing this, ending up in old resources and mixed information.
To the newer user this is way too complicated.
The structure of the Resource should be like this...
a) Where to get all the stuff
b) How to configure it - even providing make file and config changes so the user doesn't have to hack anything.
c) Support for Linux, Max and Win32
d) Link to a new forum to iron out any issues.
I believe an almost "one-click" solution can be provided if we get it right.
#22
10/09/2005 (3:17 am)
@Flybynight : I'm not sure what you mean. Please email me with an extended explanation of your request. I'm sure we can work something out. 
#23
Over the last 4 months I've been using TBE (and I appreciate all of the effort put into making it work for the community) and let me preface this whole thing with the obvious admission that I am NOT a C++ guru. Coding I understand, compiler... yeah.. not really.
What I have been experiencing is wierd glitches in certain components of the game engine. Specifically HTTPObjects and the native ZIP folder support within Torque.
I am well aware of the large number of documente dissues with HTTPOs. I would, at this point however, concider myself fairly competant at handling and utilizing HTTPOs. The problem I am encountering is that under certain circumstances the HTTPOs ghost info from previous HTTPOs at the end of the HTTPO send string (if the newer string is shorter than the previous string.) I spent a week or 2 thinking it was my scripting, changed my webserver software twice, reinstalled all kinds of different versions of the PHP and CGI engines for the HTTP server software and came to the conclusion that it was a source issue (that I assumed I had caused.) but I now find it does EXACTLY the same thing on a virgin clean 1.3 SDK install. (I am attempting to test 1.4RC2 this weekend but it's slow going) With great reservation I simply circumvented the problem by changing to striaght TCPObject communication but this has more than doubled the overhead and CPU processing of the server for each request. Not a tradgedy when you have 1 or 2 requests but when you have 100s of requests a second... You can see my concern.
The next, and far more serious issue as far as Im concerned, is that I can not for the life of me get a TBE build of 1.3 to support ZIP folders. Natively Torque supports the ability to ZIP up the contents of a folder, copy the zip up one level, rename it to the foldername.ZIP and delete the original folder. This allows for the game engine to unpack the ZIP at runtime. Using TBE you can pack certian high level folders (Such as the entire starter.FPS folder) but when you dig down deeper and try and ZIP up the terrains folder for example the engine can not find the resources. It appears to attach an incorect prefix to the path of the resource it reads from the mission file.
I have been workign with 3 or 4 other members of the GG community to try and isolate these problems as I initially thought I was at fault. Now, after testing MANY compilers, reformatting 2 of my developer machines and trying various OSs including win98, Win2K and winXP pro I have found that it IS infact the fault of the TBE compiler.
I have tried Code::blocks and eclipse and I'm now trying the manual mingw32 suggestion mentioned here. My development machines are all P4-2gig+ PCs with the OSs mentioned above. I have wiped out all Torque directories and started with fresh installs of both Torque SDK AND TBE/Eclipse.
The kicker is that if I use the pre-compiled EXE that comes with the 1.3 SDK the HTTPOs and ZIP folders work perfectly.
My summation at this point is that either it's a glitch in the makefile, the compiler, or the source. I just dont see this as being something I've done but please correct me =)
Mark
10/09/2005 (2:46 pm)
Just to document this for others using TBE I will explain the issue ( I have also sent you an email).Over the last 4 months I've been using TBE (and I appreciate all of the effort put into making it work for the community) and let me preface this whole thing with the obvious admission that I am NOT a C++ guru. Coding I understand, compiler... yeah.. not really.
What I have been experiencing is wierd glitches in certain components of the game engine. Specifically HTTPObjects and the native ZIP folder support within Torque.
I am well aware of the large number of documente dissues with HTTPOs. I would, at this point however, concider myself fairly competant at handling and utilizing HTTPOs. The problem I am encountering is that under certain circumstances the HTTPOs ghost info from previous HTTPOs at the end of the HTTPO send string (if the newer string is shorter than the previous string.) I spent a week or 2 thinking it was my scripting, changed my webserver software twice, reinstalled all kinds of different versions of the PHP and CGI engines for the HTTP server software and came to the conclusion that it was a source issue (that I assumed I had caused.) but I now find it does EXACTLY the same thing on a virgin clean 1.3 SDK install. (I am attempting to test 1.4RC2 this weekend but it's slow going) With great reservation I simply circumvented the problem by changing to striaght TCPObject communication but this has more than doubled the overhead and CPU processing of the server for each request. Not a tradgedy when you have 1 or 2 requests but when you have 100s of requests a second... You can see my concern.
The next, and far more serious issue as far as Im concerned, is that I can not for the life of me get a TBE build of 1.3 to support ZIP folders. Natively Torque supports the ability to ZIP up the contents of a folder, copy the zip up one level, rename it to the foldername.ZIP and delete the original folder. This allows for the game engine to unpack the ZIP at runtime. Using TBE you can pack certian high level folders (Such as the entire starter.FPS folder) but when you dig down deeper and try and ZIP up the terrains folder for example the engine can not find the resources. It appears to attach an incorect prefix to the path of the resource it reads from the mission file.
I have been workign with 3 or 4 other members of the GG community to try and isolate these problems as I initially thought I was at fault. Now, after testing MANY compilers, reformatting 2 of my developer machines and trying various OSs including win98, Win2K and winXP pro I have found that it IS infact the fault of the TBE compiler.
I have tried Code::blocks and eclipse and I'm now trying the manual mingw32 suggestion mentioned here. My development machines are all P4-2gig+ PCs with the OSs mentioned above. I have wiped out all Torque directories and started with fresh installs of both Torque SDK AND TBE/Eclipse.
The kicker is that if I use the pre-compiled EXE that comes with the 1.3 SDK the HTTPOs and ZIP folders work perfectly.
My summation at this point is that either it's a glitch in the makefile, the compiler, or the source. I just dont see this as being something I've done but please correct me =)
Mark
#24
Note that TBE is simply a couple of freely available packages tied together into an installer, none of which are actual GG products. Chris Calef put it together for those that have never used/cannot afford "professional" compilers and IDE's.
10/09/2005 (5:36 pm)
It's most probably outdated/not quite compliant libs that are installed as part of MinSys. You may want to check on the MinSys/MinGW forums/support areas to see if anyone has seen similar issues.Note that TBE is simply a couple of freely available packages tied together into an installer, none of which are actual GG products. Chris Calef put it together for those that have never used/cannot afford "professional" compilers and IDE's.
#25
10/10/2005 (1:01 am)
@FBN : I'll give it a go and let you know. Have you tried 1.4 as well? 
Torque Owner Flybynight Studios
Mark