On Oct 22, 2005, at 12:03 PM, Jim Kremens wrote:
It's sorta like this on an internal level - when you extend the engine it stores a reference to the extension class, and each extension can have one or more "key" Strings that will associate to it. It's a way to handle "possibly imported" classes without directly referencing them. When a key is passed in that class will be found in the lookup and used for the tween. For instance, I have this working in my next build, import com.mosesSupposes.fuse.*; ZigoEngine.extend( PennerEasing, Filters); ZigoEngine.doTween(my_mc, '__BlurFilter', {blurX:40, blurY:10, quality:2}, 1, 'easeOutBounce'); Jim, I've also made it so you can use FuseItem (object-based) syntax for any tween now. import com.mosesSupposes.fuse.*; ZigoEngine.extend( PennerEasing, FuseItem, Filters); ZigoEngine.doTween({target:my_mc, __BlurFilter:{blurX:40, blurY:10, quality:2}, seconds:1.7, ease:'easeOutElastic'}); The extended class is Filters, which sets up key strings like 'BevelFilter' etc. It's pretty much the same system that zigo set up, he passed '_ct_' as a color object - I just modified it so it would do a lookup on that key and reference the appropriate (and separate) class. As a sidenote - it also keeps the shortcuts broken into separate files which is nice since filesize is only added by request. (For instance future shortcuts like obj.blurTo won't affect filesize until you extend the engine with Filters.) I'm still trying to figure out how to handle sub-objects (such as Matrix instances or colors) within the filter object being tweened, which adds another level of weirdness.
Awesome. Do others agree?
Yeah I was sorta wondering about that... I mean it isn't "extends" so it's legal but probably bad practice? Perhaps I should come up with another method name there, like ZigoEngine.activate(classes); or ZigoEngine.register(classes); ..?
|
_______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
