[Golist] This looks a bit better as far as syntax
Moses Gunesch
moses at goasap.org
Wed May 7 07:47:57 PDT 2008
John: Yes. If you can design a system that is quickly expandable and
all you have to do is pop in some properties, I think the majority of
tweening is done on known prop names.
For special cases there could be a few generic classes that tween 'a
number on an object', 'an object in an object' and 'an array in an
object'. But I agree with you that if you have a solid set of typed
ones those are the ones you will grab for first, and save the generic
ones for special situations where you want to tween some random
variable once and it doesn't require creating a reusable class. (Of
course for those situations you can also just use a LinearGo with an
update callback so in that way, the generic tweens are barely needed
at all once you have a strong set of typed tweens.)
m
On May 7, 2008, at 8:07 AM, John Grden wrote:
> The thing about strict / strong typing is that you gain performance
> benefits, coding benefits, compiling security as well as control in
> a development environment where you have several devs working on the
> same project.
>
> Now, in the api I'm developing, I'm starting to see how easy it
> would be to abstract the properties class so that if you knew what
> properties you would ever want to manipulate, you could create your
> own properties class. For the most part, if we really think about
> it, you can create classes ( or maybe just one big one ) for
> DisplayObjects to start with. If you used Fuse like I did for
> sequencing events more than actual tweening, you can certainly
> create your own properties class for those as well. I mean, it
> makes too much sense especially in light of what you gain in terms
> of what I mentioned above.
>
> It doesn't cut you off from doing anything at all, and you gain
> quite a bit. The cost is adding 1 properties class 1 time.
>
> Thoughts?
>
> On Wed, May 7, 2008 at 12:44 AM, Sebastian Weyrauch <go at tweego.org>
> wrote:
> Hi,
>
> think this method of John is really cool too. I hate string
> properties too. But as you mentioned: For universal handling this is
> no real possibility :( If the advantage is much bigger than the
> disadvantage, you can give up strict typing, at least in my eyes.
>
>
> Maybe you're right. A universal tween class can not be that good as
> specialized classes. But I think it can be really hard to know and
> use several tween classes. And all popular tween classes are
> universal tween classes. But perhaps this will change in future. We
> will see.
>
>
> best regards
>
> sebastian
>
>
> Von: golist-bounces at goasap.org [mailto:golist-bounces at goasap.org] Im
> Auftrag von Moses Gunesch
> Gesendet: Mittwoch, 7. Mai 2008 00:06
> An: Mailing list for the Go ActionScript Animation Platform
> Betreff: Re: [Golist] This looks a bit better as far as syntax
>
>
> Hehe, sorry. And they let me write for a book! ;)
>
> Let me try again....
>
>
> Turn ons: What you're doing is better for strict typing because the
> properties are real properties – that is cool. I like how you have
> x() etc., that's really cool. In mine you had to do properties as
> strings like "x".
>
>
>
> Turn offs: I'm starting to lean against multi-property tween classes
> in general. Because, it's easy to forget how complex just ONE tween
> can be. Like, think of a color tween or a filter tween – multiple
> properties in arrays, nested in subproperties of display objects...
> gets hairy. Start values and relative values are another can of worms.
>
>
> Lately I've been thinking that a tween instance is more like an atom
> than a molecule. That's why I'm now gravitating back toward
> individual-property tween classes. That, and OverlapMonitor would be
> able to handle every property individually.
>
>
> Have not built this out though....
>
> But I'm wondering if there would some way to do that cool property
> syntax thing you're doing, but at the PlayableGroup level?
>
>
> - m
>
>
>
>
> On May 6, 2008, at 4:38 PM, John Grden wrote:
>
>
>
> 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 ] _______________________________________________
> 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 ] _______________________________________________
> 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/20080507/2af0c29e/attachment.html
More information about the GoList
mailing list