Q. nature of Torque Game Engine source code
by Steve Lewis · in Torque Game Engine · 07/08/2006 (3:17 am) · 14 replies
How "C++" is the TGE? Meaning, are all its components encapsulated within namespaces? Do you derive from classes and implement abstract interfaces (and accept the penality of virtual method calls), or do you configure callback functions (like most game engines)? How abstracted is the TGE from OpenGL and/or DirectX and their data structures? Or in general, can someone elaborate on the relationship betwen TGE and DirectX and/or OpenGL? e.g. will we still have to link in OpenGL and/or DirectX .lib files?
We want to use VS2005 Professional for our development. Do we compile the TGE and produce VS2005 .libs ourselves, or will the TGE come with .sln/.vcproj files to support VS2005 "out of the box"?
Can anyone relate TGE with GLUT? Meaning, is the TGE essentially a bunch of #define, globals, and function pointers? (and yes, I realize the TGE is much MORE than GLUT -- but I mean terms of code quality).
Are there available examples of source code that *use* the TGE? (i.e. to get a feel for how it would be used to do the general main loop of a game -- e.g. initialize the graphics, play a sound, do keyboard/mouse/joystick input, draw a rotating cube or mesh with a moveable camera, and exit on ESC -- without disclosing any of the actual TGE source?) (or is that not permitted?)
One more, just curious: Has anyone used TGE with BCB6? (I assume it doesn't have BPG/BPR project files out of the box, but I imagine it would compile under BCB6?)
Thanks!
Steve
We want to use VS2005 Professional for our development. Do we compile the TGE and produce VS2005 .libs ourselves, or will the TGE come with .sln/.vcproj files to support VS2005 "out of the box"?
Can anyone relate TGE with GLUT? Meaning, is the TGE essentially a bunch of #define, globals, and function pointers? (and yes, I realize the TGE is much MORE than GLUT -- but I mean terms of code quality).
Are there available examples of source code that *use* the TGE? (i.e. to get a feel for how it would be used to do the general main loop of a game -- e.g. initialize the graphics, play a sound, do keyboard/mouse/joystick input, draw a rotating cube or mesh with a moveable camera, and exit on ESC -- without disclosing any of the actual TGE source?) (or is that not permitted?)
One more, just curious: Has anyone used TGE with BCB6? (I assume it doesn't have BPG/BPR project files out of the box, but I imagine it would compile under BCB6?)
Thanks!
Steve
About the author
#2
07/08/2006 (8:02 am)
Well, my download of the SDK did not include the correct solution file. i had to convert a VC7 version. However, there is now a "patch" for it that has a new folder with the VS2005 files, adding that to my directory and using that solution file was very, very painfree.
#3
07/08/2006 (3:11 pm)
Thanks, that helps clarify some things. I'll give it a shot :)
#4
Here's a link to the zip off TDN that has the VS2005 project files, it worked just fine for me doing a release build, but it seems like the debug build doesn't quite work right.
07/08/2006 (4:13 pm)
tdn.garagegames.com/wiki/images/e/e8/TGE_VS2005.zipHere's a link to the zip off TDN that has the VS2005 project files, it worked just fine for me doing a release build, but it seems like the debug build doesn't quite work right.
#5
07/08/2006 (7:44 pm)
Quote: it worked just fine for me doing a release build, but it seems like the debug build doesn't quite work right.the debug exe worked fine for me.
#6
07/08/2006 (7:46 pm)
Thanks again Ramen, I got the TGE, and was having some trouble finding this "patch" :) Now working on actually doing a build.
#7
The TGE_VS2005.zip above got me the VS2005 project build files (and other code fixes to TGE). NOTE, make sure to unzip to c:\torque\sdk (and not just c:\torque).
Then I refered to some instructions available at http://tdn.garagegames.com/wiki/Torque/vs2k5 (these instructions are for VC++2005 Express, but with VS2005 Standard I just don't have to deal with the MS Platform SDK -- but good to know this all works with Express too). And I'm sure if this is working for Standard, it won't have any issues working for the VS2005 Pro version.
I did have a problem with the DEBUG build at first (I haven't tried the Release build). The problem for me was after I first installed everything, and just told it to "build" on Torque Demo (like the instructions said), it built a few of the libraries -- but it seems it didn't build the "Torque Tool Lib" before some other libraries, and it couldn't find torque_DEBUG.lib. So then I just explicitly told it to build the "Torque Tool Lib" project (which does produce that missing .lib), then built all the other library projects.
And so, I've been able to build the TGE and it's "out of the box" demo application, and run it all from within the VS2005 Standard IDE.
07/08/2006 (8:39 pm)
With a little work, I've built using VS2005 Standard. The TGE_VS2005.zip above got me the VS2005 project build files (and other code fixes to TGE). NOTE, make sure to unzip to c:\torque\sdk (and not just c:\torque).
Then I refered to some instructions available at http://tdn.garagegames.com/wiki/Torque/vs2k5 (these instructions are for VC++2005 Express, but with VS2005 Standard I just don't have to deal with the MS Platform SDK -- but good to know this all works with Express too). And I'm sure if this is working for Standard, it won't have any issues working for the VS2005 Pro version.
I did have a problem with the DEBUG build at first (I haven't tried the Release build). The problem for me was after I first installed everything, and just told it to "build" on Torque Demo (like the instructions said), it built a few of the libraries -- but it seems it didn't build the "Torque Tool Lib" before some other libraries, and it couldn't find torque_DEBUG.lib. So then I just explicitly told it to build the "Torque Tool Lib" project (which does produce that missing .lib), then built all the other library projects.
And so, I've been able to build the TGE and it's "out of the box" demo application, and run it all from within the VS2005 Standard IDE.
#8
That said, I find that I very rarely need a debug build anyway because the C++ code is only modified to add features to the engine, which is actually a somewhat rare occurance.
So far, I've added a total of two features to my copy of Torque - the ability to left click with the mouse to select an object (which I did not write myself, I found full documentation for how to do it here). After having worked that mod in, it was pretty easy to then make another mod myself that essentially added in the ability to mouselook while the right mouse button is down.
I suspect that as time goes on, I'll need to add more features but I equally suspect that we'll be upgrading to TSE before too much longer too.
07/08/2006 (10:32 pm)
Yeah... once you get the kinks out of that first build, it's all down-hill from there.That said, I find that I very rarely need a debug build anyway because the C++ code is only modified to add features to the engine, which is actually a somewhat rare occurance.
So far, I've added a total of two features to my copy of Torque - the ability to left click with the mouse to select an object (which I did not write myself, I found full documentation for how to do it here). After having worked that mod in, it was pretty easy to then make another mod myself that essentially added in the ability to mouselook while the right mouse button is down.
I suspect that as time goes on, I'll need to add more features but I equally suspect that we'll be upgrading to TSE before too much longer too.
#9
07/08/2006 (11:52 pm)
You mean to mouselook while in 1st/3rd player view (without changing the players direction)? That is a nice feature. Right now I'm looking for a way to change how far back the camera is in 3rd person view. Then I want a camera mode where the camera is stationary, but will track a player as it moves (yet without rotating into weird angles). All probably done before, just have to search the forums :)
#10
I like the stationary camera thing... that sounds very cool. Could see use for that in the ol' racing game "TV announcer" playback mode.
07/08/2006 (11:55 pm)
Actually, not quite... what I mean is that I have the mouse pointer enabled so that the player can click on items, so needed to add in mouselook to right click because by default when the mouse pointer is enabled you cannot use it to move.I like the stationary camera thing... that sounds very cool. Could see use for that in the ol' racing game "TV announcer" playback mode.
#11
The TGE terrain and GUI editors themselves are fun to play with, and you can do quite a bit without doing a single line of C++. Absolutely, the TGE will save us a ton of time.
07/09/2006 (12:20 am)
To answer my own original question: the TGE code itself is pretty good, not sloppy amateur material. Sure, I've seen a better math library (e.g. in what I've spot checked, the TGE isn't taking much advantage of templates or operator overloading {there are tricks with those that can improve runtime performance -- e.g. avoid passing certain data across on the stack by making it a compile time template parameter, avoid creation of extra temporary during compound statements, etc}, not everything is namespace encapsulated {just the usual potential for name collision while integrating future 3rd party software}, some portions are raw C -- like the JPEG reader, not all constructors are using initializer list to initializer class members, etc.). But in general the style is clean, they used the "m" convention for private class members, and at least some attempt to take advantage of the const keyword. Good stuff, not some "kid hacker" crap (where it's like they think they are doing anyone any favors by using the least amount of spaces and indentation in their code :)The TGE terrain and GUI editors themselves are fun to play with, and you can do quite a bit without doing a single line of C++. Absolutely, the TGE will save us a ton of time.
#12
The diagrams by directory are still pretty big, but not nearly as bad.
07/09/2006 (1:09 am)
Yeah, in building my UML diagrams of the code base, I found I had to force diagrams by directory because by namespace there was one really gigantic diagram (that I couldn't load half the time because it was so big, and certainly couldn't use) and a handful of tiny ones.The diagrams by directory are still pretty big, but not nearly as bad.
#13
Kudos on realizing that a proprietary diagram to suite your specific needs was the way to go. Still, code is king, imho :)
07/09/2006 (3:34 am)
Ha! I try to burn every UML book that I come across (ok, not literally :). As soon as a project involves more than about a dozen boxes (e.g. classes), diagramatic representation of software just falls on its face (IMO). UML spaghetti diagrams are like old procedural spaghetti code: evil madness. It's taken us years to cure UML fever from our own organization! Kudos on realizing that a proprietary diagram to suite your specific needs was the way to go. Still, code is king, imho :)
#14
I tend toward really hardcore architecture in any project I'm involved with though, it has saved my tail more than once.
07/09/2006 (7:19 am)
Actually, putting the diagrams together helped me to understand the code base a whole ton. It's kind of hard to gain an overview of a million lines of code (MLOC to IBM old-schoolers... heh) just by reading the code.I tend toward really hardcore architecture in any project I'm involved with though, it has saved my tail more than once.
Torque Owner Chris Schletter
Yes it comes with out of the box support for VS2005.
You user can use either DirectX or OpenGL when running a version compiled for the Windows platform.
By default, you do have to link to the OpenGL and DirectX .lib and .h files for compilation and linking.