[Golist] This looks a bit better as far as syntax

[John Grden]

So I'm confused a bit -seems like you said you were leaning towards 1
property per tween that exists, but you like what I'm doing with that last
code sample

LOL I know I missed something

I think that I started to get what you meant though - having those apart of
a PlayableGroup etc is essentially what we end up with, is that about right?

On Tue, May 6, 2008 at 3:17 PM, Moses Gunesch <moses at goasap.org> wrote:

> Yeah that's good. I created a system called OpenTween – don't think I ever
> posted it though because I wasn't sure I liked the abstraction layer of
> putting a ton of information and functionality into property classes which
> is what happened when I tried this.
> My property inputs were
>   propName: String,
>   endVal: *=null,
>   endValRelative: Boolean=false,
>   startVal: *=null,
>   startValRelative: Boolean=false
>
> Then I had this functionality in there from Fuse, that lets you omit
> either start or end and it will figure it out. That's probably why it got
> complicated.  (I will share OpenTween if you want.)
>
> Anyway yeah I think there is something to a multi-property approach for
> sure, but I've been leaning back toward just extending LinearGo in the
> simplest way possible – one property per tween class. **
> *
> *
> *Here is why:* if every single property were in a separate tween class,
> OverlapMonitor works the best in that it can allow just one property to be
> paused, stopped and so on. That's how ZigoEngine worked, it atomized every
> tween internally. I've been thinking PlayableGroup could be extended to
> handle multi-prop tweens by creating separate tween instances, then it could
> let you drill into them to grab children by property etc.
>
> One could argue that it's slower to not block all similar tweens, but it
> also provides more control and is less abstract, and I've found that in real
> practice there are usually only a very small number of "blocked" tweens at
> once... pretty soon you want to change delay/duration/easing on one property
> or another and you end up with a group anyway.
>
> That said, I'd love to see your concept taken all the way John...!
>
> :-)
>
>
> On May 6, 2008, at 3:54 PM, John Grden wrote:
>
> *Was this:*
> tween_0 = new Tween3D(target, 1, Equations.easeOutCubic);
> tween_0.x = 0;
> tween_0.y = 50;
> tween_0.rotationZ = 0;
> sequence.addStep(tween_0);
>
> sequence.lastStep.advance = new OnDurationComplete(.2); // advance
> early/overlap
> tween_0b = new Tween3D(target, 1, Equations.easeOutCubic);
> tween_0b.z = 200;
> sequence.addStep(tween_0b, true); // 2nd param groups it with previous
> step. param is "addToLastStep"
>
> tween_1 = new Tween3D(target, 1, Equations.easeOutCubic);
> tween_1.x = -10;
> tween_1.y = 85;
> tween_1.rotationZ = 15;
> sequence.addStep(tween_1);
> sequence.lastStep.advance = new OnDurationComplete(.25); // advance
> early/overlap
>
> tween_2 = new Tween3D(target, 1, Equations.easeOutBounce);
> tween_2.rotationX = 0;
> tween_2.rotationY = 0;
> sequence.addStep(tween_2);
>
> *Is now this:*
>
> tween_0 = new Tween3D(target, [Go3D.x(0), Go3D.y(50), Go3D.rotationZ(0)],
> 1, Equations.easeOutCubic);
> sequence.addStep(tween_0);
> sequence.lastStep.advance = new OnDurationComplete(.2); // advance
> early/overlap
>
> tween_0b = new Tween3D(target, [Go3D.z(200)], 1, Equations.easeOutCubic);
> sequence.addStep(tween_0b, true); // 2nd param groups it with previous
> step. param is "addToLastStep"
>
> tween_1 = new Tween3D(target, [Go3D.x(-10), Go3D.y(85),
> Go3D.rotationZ(15)], 1, Equations.easeOutCubic);
> sequence.addStep(tween_1);
> sequence.lastStep.advance = new OnDurationComplete(.25); // advance
> early/overlap
>
> tween_2 = new Tween3D(target, [Go3D.rotationX(0), Go3D.rotationY(0)], 1,
> Equations.easeOutBounce);
> sequence.addStep(tween_2);
>
>
> I'm still thinking about this approach, but thought I would throw it out
> to you guys to see what you thought.  Right now, there's static methods in
> Go3D that return a Go3Dproperty.  Tween3D has an array called
> propertyChanges and if there is an array in the propertyChanges argument, I
> just set it straight away - no parsing required.  It's all ready to go and
> is filled with Go3DProperty objects.
>
> Thoughts?
> --
> [ JPG ] _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org
>
>
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org
>
>


-- 
[ JPG ]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080506/d8e48324/attachment.html