See what's going on with flipcode!




This section of the archives stores flipcode's complete Developer Toolbox collection, featuring a variety of mini-articles and source code contributions from our readers.

 

  Event sequencing: Building dependancy trees
  Submitted by



In a game there are two main things we need to sequence, namely graphix, and sounds. We need this to be as simple as possible. So we create a layer, or a kind of proxy between the calls to the gfx, and sound objects, and the actual implementation thereof. This middle layer being a command sequencer, or event sequencer if you like which will send off tag values to objects which, on startup, would have subscribed for them and know how to map them back to the associated method call.. Based on the publisher / subscriber model, command sequncer allowes us to perform synchronous, asynchronus calls to the sound, and gfx objects with ease. Another feature is event reference counting, or locking, and unlocking.

The main feature is creating dependancy graphs. eg:

  event A, B, and C can only occur once D, and E are done.
  then, event X occurs as soon as one of A,B, or C are done.
      D , and E processing...

Complete D, and E

A, B, and C processing...

Complete A, or B, or C

X processing.

And so forth, and so on.

Thus allowing for any combination of events, with whatever dependancies we need. At the end of the day, each event, ie: X, Y Z, or whatever we choose to call, typically maps back to a method call with the associated data-set.

eg:
SpriteMethodA(INT i);

ManagedSpriteMethodA(INT i,INT nDependancyListOfEvents...);

To invoke SpriteMethodA, we use the ManagedSpriteMethodA version which, internally, makes use of our command sequencer to send off the command to the SpriteObject itself. As you can see, we have the option of Making SpriteMethodA dependant on as many existing events, nDependancyListOfEvents, as we like.

Maybe a pseudo code snippet...

// Subsriber object A
   Subscribe for command X_Visible
   Subscribe for command Y_Animation

OnCommand(INT CommandId,INT ReturnID) { if(CommandId == X_Visible) { set object visible Ack(ReturnID); // Tells the command sequencer we are done processing // this tag, and are ready for the next. } if(commandId == Y_Animation) { play animation save ReturnID for later usage when animation is done. } }

OnAnimationDone { Invoked Ack(ReturnId) on previously saved ReturnId from the OnCommand method. } // Lets say we have these 2 managed methods using the command sequencer to post of the // X_Visible, and Y_PlayAnimation commands to the relevant objects. INT ManagedSpriteSetvisible(INT nAnimationID,INT nDependancyList...); INT ManagedspritePlayAnimation(INT nDependancyList...);

// The actual game module making use of the ManagedSprite object. // The animation will start right away since we have no dependancied in the list. INT nAnimationHandle = ManagedSpritePlayAnimation(animation_id_1,END_DEPENDANCY_LIST); // The sprite will only be set to visible once the animation has completed. INT nVisibleHandle = ManagedSpriteSetVisible(nAnimationHandle,END_DEPENDANCY_LIST);

// Here we can see the dependancy used when invoking the sprite set visible method.

Peter Lewis

The zip file viewer built into the Developer Toolbox made use of the zlib library, as well as the zlibdll source additions.

 

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.