[Golist] OverlapManager and delays
Moses Gunesch
moses at goasap.org
Fri May 16 08:50:45 PDT 2008
Thanks for the kind words Christian! I hope that you know about the Go
Demo Contest in progress (http://go.mosessupposes.com/) and will be
turning out a stunning demo for my FlashBelt talk.
-
I understand what you are saying here, that you would like to delay
management during delays.
This is the "proper way" to do what you're trying to do:
var s:SequenceCA = new SequenceCA();
s.addStep(new PropertyTween(sprite1, 4, Sine.easeOut, 'x', 400));
s.lastStep.advance = new OnDurationComplete(3); // early advance
s.addStep(new PropertyTween(sprite1, 4, Sine.easeOut, 'x', 400));
s.start();
Still only 5 lines of code; not bad. This does require that more
classes are compiled, but to avoid using SequenceCA, you could still
do the same thing by setting up a Timer that would generate the second
tween.
-
This touches on a finer point of what you could call "tween engine
theory".... let me explain it a little.
In the ZigoEngine days I switched things to always honor a tween as a
tween. Making a tween call, regardless of delays, is making a tween
call – you are triggering an active handling of a target even if that
handling is delayed. Sequencing, on the other hand, is specifically
made to play tweens at different points in time which is what you are
trying to do here. Therefore, at least on a pure theory level :-) this
particular problem should be solved with sequencing. I think I also
went that way because allowing tweens to run "hidden" caused some real
problems with Fuse being able to track interruptions. It removes your
system's ability to detect that a tween is active.
I'm not saying I don't like your solution though, and your
implementation is fine. If you don't like the Sequencing solution
above, I would also say that you could build another manager that
would work differently... you are not locked into using or modding
OverlapMonitor. But, modding it is also okay of course. :-)
- m
On May 16, 2008, at 11:11 AM, Christian Auth wrote:
> hey moses,
> hey list,
>
> just checked out the go system and dude you rock!.
> you are the first person who wrote a os lib where i felt at home
> instantly.
> i just wrote a near complete animation suite for out own framework
> at work and
> it was incredible easy to implement. i just had to think about the
> way i want the
> animation "language" to look like.
>
> so, that was the love part (;
>
> until now the overlap manager worked fine for me. but while testing
> delays i found a rather
> unexpected (at least for me) behaviour. if you tween the same
> property on the same target
> with one of them having a delay one of both will be killed by the
> overlap manager.
>
> Code:
> var tween1:PropertyTween = new PropertyTween(sprite1, 4,
> Sine.easeOut, 'x', 400);
> tween1.start();
>
> var tween2:PropertyTween = new PropertyTween(sprite1, 4,
> Sine.easeOut, 'x', 10);
> tween2.delay = 3;
> tween2.start();
>
> the problem is that the property matching is handled when calling
> start(). i don't know
> if you did that for a good reason but i got it working by doing this :
>
> LinearGo.as
> /**
> * Performs tween calculations on GoEngine pulse.
> *
> * <p>Subclass <code>onUpdate</code> instead of this method.
> *
> * @param currentTime Clock time for the current block of
> updates.
> * @see #onUpdate()
> */
> override public function update(currentTime:Number) : void
> {
> if (_state==PAUSED)
> return;
>
> _currentFrame ++;
> if (_useFrames)
> currentTime = _currentFrame;
>
> if (isNaN(_startTime)) // setup() must be called
> once prior to tween's 1st update.
> setup(currentTime); // This is done here, not
> in start, for tighter syncing of items.
>
> if (_startTime > currentTime)
> return; // still PLAYING_DELAY
>
> //add to managers (added by chra)
> if (!_started)
> {
> GoEngine.manageItem(this);
> }
>
>
> GoEngine.as
> /**
> * Adds an IUpdatable instance to an update-queue
> corresponding to
> * the item's pulseInterval property.
> *
> * @param item Any object implementing IUpdatable
> that wishes
> * to receive update calls on a pulse.
> *
> * @return Returns false only if this item was
> already in the
> * engine under the same pulse. (If an
> existing item is added
> * but the pulseInterval has changed it
> will be removed,
> * re-added, and true will be returned.)
> *
> * @see #removeItem()
> */
> public static function addItem( item:IUpdatable ):Boolean
> {
> --- snip
> // Report IManageable instances to registered managers
> (changed by chra)
> /*
> if (item is IManageable) {
> for each (var manager:IManager in managers)
> manager.reserve( item as IManageable );
> }
> */
> return true;
> }
>
>
> /**
> *
> */
> public static function manageItem( item:IUpdatable ):Boolean
> {
> // Report IManageable instances to registered managers
> if (item is IManageable) {
> for each (var manager:IManager in managers)
> manager.reserve( item as IManageable );
> }
> return true;
> }
>
> cheers
> Chris
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080516/e77f8ecd/attachment.html
More information about the GoList
mailing list