Release: Tinkerbell Tweening Engine
Juraj Kirchheim
I'd like to proudly announce, that Tinkerbell now bundles tink_tween,
a cross-platform tweening engine. Hadn't had time to write proper
documentation just now, but here are things in a nutshell:
Because tink_tween uses macros to create tweens, it is type safe and
will therefore leverage all of haXe's compile time features (such as
proper accessor invocation, inlining and so on).
This is what a tween would look like:
using tink.tween.Tweener;
target.tween(x = 5, y = 6, scaleX = .5, scaleY = .3, $duration = 2,
$onDone = trace('done tweening '+tween.target), $easing = function
(x:Float) return x * x);
All non $-prefixed parameters apply to the target, all $-prefixed ones
are tween parameters. Please note that $onDone accepts an expression
of type Tween<A>->Dynamic or will transform the expression into a
function, where `tween` is the current tween.
And here comes the fun part, I've been working on last night: Plugins!
Through plugins, tink_tween supports (much like other tween libraries)
tweening blurX, blurY through BlurFilter, saturation, hue, contrast
and brightness through ColorMatrixFilter and the good old autoAlpha
and smartRotation. Please not that those concrete plugins are platform
dependent, unlike the rest of the engine.
You can see them in action here: http://back2dos.de/tweenplugins/
The "click areas" on top will respond to your mouse position, i.e.
clicking "brightness" at the right edge makes the logo white, and at
the left edge makes it black. Same for the other four.
The source is here: http://back2dos.de/tweenplugins/Features.hx,
compile with haXe SVN and Tinkerbell.
Have fun playing around with it ;)
-------- (Performance - for those who care) --------
As is tradition with tweening engines, I have also done a few
performance tests, showing that tink_tween is currently roughly at par
with Actuate, although speaking of pure "transformation" time (without
the flash player rendering) Actuate is some 10-20% faster (on my
machine anyway):
With rendering:
- tink_tween: http://back2dos.de/tweenperformance/?lib=tink_tween&count=2000
- Actuate: http://back2dos.de/tweenperformance/?lib=actuate&count=2000
Without rendering:
- tink_tween: http://back2dos.de/tweenperformance/?lib=tink_tween&count=5000&render=false
- Actuate: http://back2dos.de/tweenperformance/?lib=actuate&count=5000&render=false
The source to the test can be found here:
http://back2dos.de/tweenperformance/Performance.hx
Please note that you can also run it with feffects, which turns out to
be slower. Compile with haXe SVN, Tinkerbell, lib -actuate and lib
-feffects.
Technically, tink_tween has a lot of room for performance improvement,
because currently it uses anonymous functions for the heavy lifting.
Instead, it could declare functor classes at macro time and also pool
their instances. I will investigate this in future versions.
I've also stripped the test down to run with NME. For html5,
tink_tween was some 30% faster, for windows binary, Actuate seemed
almost twice as fast.
-------
As is, the library is usable and largely tested. I will submit it to
haxelib as soon as haXe 2.09 is released. Proper documentation is also
in the pipe.
I suggest you don't write your own plugins just yet, because that part
is not unlikely to change.
Looking forward to any feedback!
greetz
back2dos
Simon Krajewski
> Hiho,
>
> I'd like to proudly announce, that Tinkerbell now bundles tink_tween,
> a cross-platform tweening engine. Hadn't had time to write proper
> documentation just now, but here are things in a nutshell:
Nice! I had a quick look at it and it seems quite flexible and easy to
use. I like how tweens are ticked centralized by e.g.
Tween.useEnterFrame. Here are some questions/suggestions:
- Why can't I use fps based ticking on flash? It seems unnecessary to
constrain this to JS platform.
- Is there any obvious way of pausing tweens? Maybe introduce an
isPaused field to Tween, that is checked upon ticking.
- By creating the haxe.Timer as a local variable in Tween.setFPS, you
seem to lose some control over progression. Why not make it a static
member of Tween so you can handle subsequent calls to setFPS better,
allowing the user to change the fps during runtime by resetting the
timer to a new fps value?
- Will you release parts of tink as separate libs on haxelib as you did
with tink_macros? I like having this kind of optional separation.
- What's a hearbeat? ;)
Simon
Juraj Kirchheim
> I like how tweens are ticked centralized by e.g. Tween.useEnterFrame. Here
> are some questions/suggestions:
Let me reorder them:
> - What's a hearbeat? ;)
The heartbeat is what makes the engine run. You pass it a time delta
explicitly, or have it determined automatically.
See this test: https://github.com/back2dos/tinkerbell/blob/master/tests/src/tween/TweenTest.hx
It is not dependent on actual time and thus works on PHP just as well.
> - Why can't I use fps based ticking on flash? It seems unnecessary to
> constrain this to JS platform.
On the flash platform, the player has it's own frame based update
cycle. Updating out of sync makes no sense. On JavaScript, there is no
such notion of a "frame", so the update interval is picked
arbitrarily, as `1 / desiredFramerate` seconds.
> - Is there any obvious way of pausing tweens? Maybe introduce an isPaused
> field to Tween, that is checked upon ticking.
Will add this in the next update.
> - By creating the haxe.Timer as a local variable in Tween.setFPS, you seem
> to lose some control over progression. Why not make it a static member of
> Tween so you can handle subsequent calls to setFPS better, allowing the user
> to change the fps during runtime by resetting the timer to a new fps value?
Using any of those calls is optional. You can build your own mechanism
around heartbeat if necessary.
Currently, I am not too happy with either of them just yet to be honest.
> - Will you release parts of tink as separate libs on haxelib as you did with
> tink_macros? I like having this kind of optional separation.
That's the plan, yes :)
Simon Krajewski
>> - What's a hearbeat? ;)
> The heartbeat is what makes the engine run. You pass it a time delta
> explicitly, or have it determined automatically.
> See this test: https://github.com/back2dos/tinkerbell/blob/master/tests/src/tween/TweenTest.hx
> It is not dependent on actual time and thus works on PHP just as well.
I was just trying to report the typo, you're missing the t in hearTbeat. :)
> On the flash platform, the player has it's own frame based update
> cycle. Updating out of sync makes no sense.
Okay, I'm perhaps thinking too much in terms of classical separation of
movement and display. Since this is a tweening engine and not a physics
integrator, limiting it to the framerate should be fine.
> Using any of those calls is optional. You can build your own mechanism
> around heartbeat if necessary.
> Currently, I am not too happy with either of them just yet to be honest.
That calls for tink_timer, the all-in-one timer utility for haxe that
works on all platforms and allows both delta time usage and binding to
the flash framerate!
Simon
Dima Granetchi
Juraj Kirchheim
At times like these I realize how perfectly auto-completion allows
replication of the same typo over and over again :-D
>> On the flash platform, the player has it's own frame based update
>> cycle. Updating out of sync makes no sense.
>
> Okay, I'm perhaps thinking too much in terms of classical separation of
> movement and display. Since this is a tweening engine and not a physics
> integrator, limiting it to the framerate should be fine.
Oh, I haven't really thought along those lines at all. It's an
interesting thought, but I think a physics integrator is better to
work on well-defined entities, rather than manipulating properties of
arbitrary objects.
>> Using any of those calls is optional. You can build your own mechanism
>> around heartbeat if necessary.
>> Currently, I am not too happy with either of them just yet to be honest.
>
> That calls for tink_timer, the all-in-one timer utility for haxe that works
> on all platforms and allows both delta time usage and binding to the flash
> framerate!
My point was rather, that I don't want this behavior to be global. But
I already have a solution to that in mind ;)
Juraj Kirchheim
> Looks great. Runtime properties reflection looks great.
Thank you!
Still, it is important to understand that tink_tween uses runtime
property reflection *only as a fallback*, if the tween target is typed
Dynamic. It is not advised to tween over Dynamic, simply because it's
*a lot* slower, not type safe and doesn't work with plugins either.
Regards,
Juraj