Tuesday, April 17, 2001

Startup / Shutdown dichotomy

When a Director movie begins playing, it goes through a series of initialization routines, in different contexts, before the normal operation of the movie continues. The first thing Director does is call a handler called prepareMovie. It then initializes all the sprites, and their beginSprite methods are called. Once the engine is all set up, Director callled startMovie.



This provides the necessary separation of initialization routines that allow us to set up code structures which the sprites need access to, and for starting up code structures that depend on sprites (and their behaviors) having registered themselves. This is all fine and good.



Director is not so good at shutting down, however. You would expect that there would be a parallel structure for when we want to shut down a movie: a stopMovie call, endSprite calls, and...what? There is no equivalent for prepareMovie method that is called after all the endSprites. If you initialize some code structure that supports sprites, which sprites need to reference as they shut themselves down, you're out of luck.



To provide a real example, suppose you wanted to write a program that uses FileIO to write out a log of everything your sprites do during a movie, say for debugging. You would initialize the FileIO xtra in preparemovie, and open the file. You could then write out sprite startup messages to the file in the beginSprite handlers. But when you go to shut down, you can't write out messages in the endSprite handlers if you shut down the xtra in the stopMovie handler, because that will execute before the endSprite handlers. And there is no handler that will execute after the endSprite handlers. You are forced into the inelegant solution of jumping to a blank frame in the stopMovie handler, which will trigger the endSprite handlers, and then do your cleanup.



This lack of cleanup options extends beyond this single issue, however. Director allows you to specify code to execute when an object is created (using the new command) in the standard way one might use a constructor in C++ or Java. But there is no destructor handler for objects. You cannot define code to be called when your object gets purged from memory - you must track all that manually and call a predefined method in your object when you delete it.



It would be nice to get some features that allow us to shut things down as elegantly as we start them up.