A day in the C++ life of T2D

So, you're not content with a TScript-driven Torque2D. You want to have code run the show. You want to have TScript as helpers, not masters.

But, of course, the design is working against you. There's no interface for it. If you want to do this, you're going to have to hack the code in order to make it possible.

So, where does this go? That's what we're going to explore; the C++ internals of T2D's initialization and game loop. Note that I have not yet attempted to create a functioning T2D using an alternate initialization sequece or from adding additional elements to the game loop. This discussion is for how the standard T2D loop works with discussion as to which steps load/run scripts and where the user might best insert code.

Obviously, it all starts in main() (found in, if you're using Windows, platformWin32/winWindow.cc). However, this function does rather important initialization (and deinitialization) stuff that you'd probably do well to not touch. The next step is an abstract class (yay!) called "GameInterface".

It is an abstract class, but it is also a class that has functionality. It provides "Journal" functionality; you can read more about this in the comments to "gameinterface.h". It is not important for our needs.

What is important are the virtual functions of GameInterface. Specifically:

virtual int main(int argc, const char **argv);
   virtual void postEvent(Event &event);
   virtual void processEvent(Event *event);
   virtual void processMouseMoveEvent(MouseMoveEvent *event);
   virtual void processInputEvent(InputEvent *event);
   virtual void processTimeEvent(TimeEvent *event);

The real C/C++ main() function does initialization and then calls the global GameInterface object's (called "Game") main() function. No scripts have been loaded; only the most basic setup has been done. There isn't even a game window yet. It is GameInterface::main() that is expected to handle all the significant initialization, like creating a game window and so forth.

The standard T2D build comes with a derived and fully implemented child class of GameInterface called DemoGame. We will be using this implementation as a basis for user-defined implementations.

DemoGame is declared in game/demogame.h, but the definitions are all in game/main.cc.

The very first thing that DemoGame::main() does is call initLibraries(), a static function that does what it says. If it returns 0, then it failed.

After this, the next big step is running the global function initGame(). It takes the same arguments as main(), and it's job, among a few other things, is to run the user-specified startup script. This is clearly a step that should be avoided/ignored if the user is wanting to build the game from code rather than script. However, initGame() does some other things as well, like calling Sim::init(). I haven't investigated this step, but from a cursory glance, I wouldn't suggest not calling this function. It also creates an action map named "GlobalActionMap". It is up to you whether or not you care about this.

Now, we enter the main game loop. As such, if you want to do some code initialization before this (perhaps something like what your TScript would do in the setupT2DScene() function), feel free. Though the initGame stuff should probably happen first, so that the simulation is ready. In later looks at initializing T2D manually, I'll be walking through TScripts to emulate what they do in C++.

Here's the main game loop code in question:

while(Game->isRunning())
   {
      PROFILE_START(MainLoop);
      Game->journalProcess();
      Net::process();      // read in all events
      Platform::process(); // keys, etc.
      TelConsole->process();
      TelDebugger->process();
      TimeManager::process(); // guaranteed to produce an event
      PROFILE_END();
   }

<Why do we have this silly character limit? Posts with sentences are good.>