Game Development Community

Suspending torque processing temporarily

by Morphonix LLC · in Torque Game Engine · 03/23/2005 (10:56 am) · 2 replies

I would like to be able to let another application take over control of the window for a while...

Specifically I want to use the Quicktime API to play cutscene movies w/o having to chunk them up like the guiChunkedBitmapControl does. I just want to get the window handle for the application window, and then tell torque to not interfere for a while.

Has anyone done this?

#1
03/23/2005 (11:46 am)
Does guiChunkedBitmapControl work now? Haven't tried it for more than a year.
#2
03/24/2005 (6:58 am)
For still bitmaps yes, not for movies. I was referring to the strategy of breaking up the full frame into multiple sub frames in order to allow full coverage. (i.e. if you want to have a 800x600 image as a backdrop.) There are a couple of movie player resources out there that use a similar approach.

I was hoping to use a more general approach for movies where Torque would just relenquish control to another library for a time, instead of shoehorning video into a bitmap under the control of the Torque GUI.

Granted, there is something to lose when doing this, but for something like a cutscene movie, the performance gain and simplicity are attractive.

I've started with something like this: (brief discussion follows)

// Main loop

   while(Game->isRunning())
   {
      if (Game->isSuspended())
         continue;

      ....

   }

then added the following to GameInterface:

class GameInterface
{
   ...

   bool mSuspended;

public:

   ...

   void setSuspended(bool suspended) { mSuspended = suspended; }
   bool isSuspended() { return mSuspended; }
};

Please excuse the use of the word 'Suspend' here, as it's not the proper suspension of multi-threaded code (a spin-lock? yes?)

The movie player lib would get the window handle, and call "Game->setSuspended(true)". It would do its stuff, and then call "Game->setSuspended(false)" to pass control back to Torque.

Of course, the movie player would have to be in another thread... so the above would probably be better off using true multithreaded primitives. (e.g. grab and release a Mutex instead of the call to Game->isSuspended() ?).

Is this sounding reasonable? or are the danger bells ringing?