If I might, I'd like to ask for more information about the Tickable and Positionable interfaces.

Tickable (and the set and queue) just has a Tick() method... no floating point time parameter.  I'm assuming Tick() would be a time event and I need to implement a "tick clock" myself... something to add up floating point frame times, call Tick() and reset itself when the sum exceeds a certain time period.  Is that the intent of the Tickables?  Or since there's no Tick clock included in the framework are the Tickable variants more intended to be used just as event counters?

Positionable confuses me a little, too.  Here I'm assuming something like the eye of a gooball would be a Positionable, as would the body of the goo ball.  Then if the eye moves relative to the body, when getPosition() is called, the correct global position of the eye would be calculated and returned.  If the eye hasn't moved, it'll just return the previously cached value.
  What confuses me though is that if the body moves but the eye doesn't move relative to it, what will be returned from getPosition() of the eye will be wrong... it'll be the cached value of the eye position + the old position of the body.  ( I'm assuming the mAnchor of the eye is set to the body )  On the other hand, if I'm only worried about the position of the eye for drawing, then I could simply update the graphics matrix stack with the position and rotation of the eye relative to the body (the member values) and I wouldn't use the getPosition() call at all.  Are Positionable nodes in a tree intended to add functionality to track their child nodes and dirty the children's mPosRegisterDirty when they move?  Or am I misunderstanding what Positionable should be used for?

Thanks for your help.

You're right; the Tickable interface isn't tied into the rest of the framework, so you have to `manually' tick objects. Fortunately, the framework calls your Game::update() method at a fixed interval, so an easy way to tick objects is to add them all to a TickableSet and then call its tick() method once in update().

Note that the general pattern is that BoyLib contains utility stuff which does not depend on anything in the Boy directory, so you'll find a lot of stuff there that is optional (you don't have to use it all), doesn't interact directly with the environment, but can be used if you tie stuff together yourself.

As for the Positionable class; I'm not sure what to make of that myself, so maybe someone else can fill that in. :)

I hear what you're saying about the BoyLib utilities being completely optional.  In fact, I initially starting writing stuff using almost nothing from BoyLib.  But then I figured I was being dumb, rewriting a bunch of stuff that was already there for me to use.  So I'm just spending a little time to figure out how to make as much use of available parts of the framework.

I couldn't see Game::update() getting called at a fixed interval.  I did see however that you can set a "refreshrate" parameter in the config.txt file to set a maximum frame rate, which, as long as the app can maintain that rate amounts to the same thing.  Is that what you meant?

The Positionable class really has me scratching my head.  I wonder if the magic is simply that every Positionable must update its position every frame, even if it hasn't moved (i.e. call SetPosition() on itself with its old position vector)  That would work I guess, but then that assumption makes the mPosRegisterDirty variable redundant.  So I still don't think I've got it.  >working<

FWIW, I'll post my best guess on Positionables.

Positionables should be updated every frame.  If they don't move, they just update the mPosRegisterDirty to true.  (mPosRegisterDirty is protected, and that seems to be reasonable reason why it would be.)
Doing that means getting the global position of each Positionable can be done in any order, with the efficiency of only needing to calculate the global position of each once per frame and without incurring the expense of one or more matrix multiplications per Positionable.

I haven't tried this out yet, but it seems like it's right and if it works that way it's a pretty elegant approach.  I need to think in trees more often...