[Golist] tween classes versus all-in-one

Karsten Goetz KarstenGoetz at web.de
Mon Apr 21 02:12:10 PDT 2008


Hi Coders,

I like the idea to seperate into different tweens.
I tried to do something like this a few weeks ago - but the work is  
not finished and has some bugs.
I've submited them anyway to SVN in my package ( KarstenGoetz ). If  
you are interessted, have a look.

I tried to set up some "interactive test", too ( not post to svn ).
What I mean is some more  complex animation that starts on mouseover,  
rewinds on mouseout and perhaps do
some new animation on click from the given position... in other  
words, i played around.
I don't have results from this session but some questions:
- how would you arrange such an animation?
- I sometimes miss a more timebased handling of tweening. We can play  
forward and skipTo - but what about rewind a tween and rewindTo?
Imagine a slider, representing the animation time, you drag it and a  
tween, group or sequence would calculate the animation at this time.

I get a bit confused about this things, so I want to ask you. For me  
LinearGo and PlayableGroup ( and Sequence ) are leaving the  
"lightweight"-zone ( I'm pointing here to the implementations of  
Repeater and useFrames - all absolutly nessesary, but I start to miss  
the basic thing... ).
I think a basic Tween ( LinearGo, or maybe a new Class called  
TimeGo?;- ) should be more timeline-like. In my point of view it's  
not far away and I started to create some experients on that to try  
if its possible. I think it is  - but is it a way? Maybe I'm  totally  
wrong? Maybe I've missed some tools in Go that doing this stuff.

Lots of greetings

Karsten






Am 17.04.2008 um 18:56 schrieb Moses Gunesch:

> On Apr 17, 2008, at 10:41 AM, Tollman Owens wrote:
>> I can only see the benefit of doing all of the extra functionality in
>> external classes for legibility, because you are going to
>> get the weight when you do the import, so being able to save file  
>> size
>> is not really an issue, please correct me is i am wrong.
>
> It's not about legibility, it's about modularity.
>
> Think about it from an Object-Oriented and Open-Source Sharing
> perspective: Whoever extends LinearGo with the best (simplest, most
> coherent, most functional) set of basic tween classes will be
> providing a bedrock foundation for everyone else.
>
> The most attractive set of basic tween classes put out by one of you
> should end up receiving a VERY high adoption rate, because this set of
> basic tween classes can be repurposed for ANY parser or more complex
> system. No one has so far realized this and picked up the gauntlet
> but, I'm freely handing it to all of you for the taking. So go ahead,
> get famous if you want. ;-)
>
> Such a set is not included in GoASAP in order to maintain purity:
> Go is a base system that doesn't propose any specific syntax, not even
> for tween classes, because there are so many approaches to that
> interface.
>
>
> A basic list of tweens might be something like this:
>   * A DisplayObject tween
>   * A generic any-object/ any-property multiple-value tween
>   * A generic any-object/ any-property multiple-value tween
>   * A ColorTransform tween (could subclass the multi-value tween)
>   * A BitmapFilter tween
> 	(could be several of them since some filters are multi-value)
>   * A Bezier-arc tween
>
> Just my two cents.
>
> moses
>
> _______________________________________________
> GoList mailing list
> GoList at goasap.org
> http://goasap.org/mailman/listinfo/golist_goasap.org

------------------------
Karsten Goetz
Flashprogrammierung

Bernstorffstr. 120
22767 Hamburg

Tel:       +49 40 43 09 91 07
Mobil:   0173 57 14 984



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://goasap.org/pipermail/golist_goasap.org/attachments/20080421/749ff919/attachment.html 


More information about the GoList mailing list