Learning the source code?
by Tyler Slabinski · in Torque Game Builder · 08/23/2010 (1:59 am) · 5 replies
I made a thread a little bit ago talking about manipulating particle speeds and movement in the source code. Well, eventually it came to become a thread trying to create gravity on an object through code.
Before, I never really understood how hard it was to use the source code to accomplish things dozens of times faster than script. I always thought it would be a quick option for me, and I never really looked at the code before.
Anyways, what would be the best route to learn the source code in TGB, and eventually, T3D? I already know C++, but I don't have enough time to learn OpenGL anytime soon. I know there is a book on learning the source code, but I know that was specifically designed for TGEA, which I think applies alot differently since it is 3D and focuses mostly on the networking (I also don't have TGEA so it will be hard to follow).
Before, I never really understood how hard it was to use the source code to accomplish things dozens of times faster than script. I always thought it would be a quick option for me, and I never really looked at the code before.
Anyways, what would be the best route to learn the source code in TGB, and eventually, T3D? I already know C++, but I don't have enough time to learn OpenGL anytime soon. I know there is a book on learning the source code, but I know that was specifically designed for TGEA, which I think applies alot differently since it is 3D and focuses mostly on the networking (I also don't have TGEA so it will be hard to follow).
About the author
Working on prototype.
#2
It's good to have goals, changes you want to make. Trace the code to understand what is going on then start making deep changes. It will break; that's ok. You'll learn more that way. :)
Definitely take the time to run code through the debugger by single stepping. It's a good practice for your own code, too. Use it to test hypotheses and confirm you understand how code works. In Visual Studio you can even modify variables and stuff while the code is running, good way to try what-ifs...
Read the code. :)
08/23/2010 (2:58 am)
Read all the code. That's what I did. A lot of parts didn't make sense. That's ok. I filed them away and came back to them later (in some cases many years later). I also read lots of other games' code (like the open source id games), and compared them with the Torque code.It's good to have goals, changes you want to make. Trace the code to understand what is going on then start making deep changes. It will break; that's ok. You'll learn more that way. :)
Definitely take the time to run code through the debugger by single stepping. It's a good practice for your own code, too. Use it to test hypotheses and confirm you understand how code works. In Visual Studio you can even modify variables and stuff while the code is running, good way to try what-ifs...
Read the code. :)
#3
1. Where is the class for the ConsoleMethod functions? I want to know that inputs they take and how those specifically work.
2. What kind of data types are U32, F32, S32, etc? I've never seen them before.
Most of the rest I should be able to know by reading the comments in the code and the math.
08/23/2010 (11:07 pm)
Well here are a few... Definitive questions I have:1. Where is the class for the ConsoleMethod functions? I want to know that inputs they take and how those specifically work.
2. What kind of data types are U32, F32, S32, etc? I've never seen them before.
Most of the rest I should be able to know by reading the comments in the code and the math.
#4
For example, if you do a search for U32, you'll find it defined in platform/types.h. You'll see that it's been typedef'd to an unsigned int.
ConsoleMethods are just macros. When you see one, right click on it and select "Go To Definition". It'll look like a mess, so you can ignore it for now. The basic format is as follows:
ConsoleMethod( <ClassName>, <FunctionName>, <ReturnType>, <MinArgs>+2, <MaxArgs>+2, <What to show for documentation or error messages> )
* ClassName - Your class that you are trying to tie to a method
* FunctionName - Any string you want to call your function.
* ReturnType - Typically S32, const char *, or bool (int, string, or boolean)
* MinArgs - The fewest number of arguments. Add 2 to it and put it there.
* MaxArgs - The maximum number of arguments. Add 2.
A ConsoleMethod always has "object" defined, which is a pointer to the <ClassName> instance from the scripts. It also has argc and and argv, which are exactly like the C/C++ main argc/argv. Open T2D/t2dSceneObject.cc and look at the ConsoleMethod for setPosition. You'll see that it takes 1 or 2 arguments (signified by the numbers 3 and 4). If just 1 is passed in, then it checks that the string passed in is in the form "x y". If 2 are passed in, then is assumes that x and y were passed in separately.
For the longest time, I just copied a function that was similar to what I was doing.
08/24/2010 (1:51 am)
If you are using Microsoft's Visual C++, your best friend will be Find In Files (Ctrl-Shift-F). Set it to look in your entire Solution and start your searching!For example, if you do a search for U32, you'll find it defined in platform/types.h. You'll see that it's been typedef'd to an unsigned int.
ConsoleMethods are just macros. When you see one, right click on it and select "Go To Definition". It'll look like a mess, so you can ignore it for now. The basic format is as follows:
ConsoleMethod( <ClassName>, <FunctionName>, <ReturnType>, <MinArgs>+2, <MaxArgs>+2, <What to show for documentation or error messages> )
* ClassName - Your class that you are trying to tie to a method
* FunctionName - Any string you want to call your function.
* ReturnType - Typically S32, const char *, or bool (int, string, or boolean)
* MinArgs - The fewest number of arguments. Add 2 to it and put it there.
* MaxArgs - The maximum number of arguments. Add 2.
A ConsoleMethod always has "object" defined, which is a pointer to the <ClassName> instance from the scripts. It also has argc and and argv, which are exactly like the C/C++ main argc/argv. Open T2D/t2dSceneObject.cc and look at the ConsoleMethod for setPosition. You'll see that it takes 1 or 2 arguments (signified by the numbers 3 and 4). If just 1 is passed in, then it checks that the string passed in is in the form "x y". If 2 are passed in, then is assumes that x and y were passed in separately.
For the longest time, I just copied a function that was similar to what I was doing.
#5
But I see what you mean. I was confused about how the ConsoleMethod worked because it had no type like normal functions. I also think it's a bit weird how you need to +2 for the min and max arguments.
I've never really used argc/argv, but I'll look into that. You're right though, the t2dStaticShape is really clean to read. I'll be doing most of my learning in there. I'm gonna try learning how to set breakpoints in Xcode so I can try that debug trick.
I can't find that onRender function you were talking about (the 'find' command in Xcode doesn't seem to be working very well for me), but it's getting easier to follow along. I'm rereading some of my old C++ books, since I did skip a few things that didn't seem useful (at the time). I've also been looking into books on how to optimize code. Most of them are hacking books, but they've become pretty useful so far.
08/24/2010 (3:46 am)
Well I'm using a Mac, so Xcode is my IDE.But I see what you mean. I was confused about how the ConsoleMethod worked because it had no type like normal functions. I also think it's a bit weird how you need to +2 for the min and max arguments.
I've never really used argc/argv, but I'll look into that. You're right though, the t2dStaticShape is really clean to read. I'll be doing most of my learning in there. I'm gonna try learning how to set breakpoints in Xcode so I can try that debug trick.
I can't find that onRender function you were talking about (the 'find' command in Xcode doesn't seem to be working very well for me), but it's getting easier to follow along. I'm rereading some of my old C++ books, since I did skip a few things that didn't seem useful (at the time). I've also been looking into books on how to optimize code. Most of them are hacking books, but they've become pretty useful so far.
Associate William Lee Sims
Machine Code Games
I found that the best thing to do is just to read a lot of the code. Track through what happens when you call "setVelocity" or "moveTo". The easiest way to do that is to build a debug version, set the Working Directory (in the debug build properties) to your game's main directory, set a breakpoint in one of those functions, and trace it in.
You can learn a lot about the scene structure by starting in t2dSceneWindow::onRender, and tracing to the t2dSceneGraph::renderView function.
Also, my all-time favorite is t2dStaticSprite. It's clean and simple and is easy to mimic when creating your own scene object to place in a scene graph.