The GTween library by Grant Skinner was absolutely my favorite programmatic animation library for Flash and ActionScript 3. I find the API to be intuitive, the compiled size to be lightweight, and the performance to be nice and fast. GTween provides helpful ways to sequence tweens, whether by chaining them together one after another, or by adding them at specific points on a timeline, potentially running in parallel or overlapping. It provides a plug-in API too, which makes it possible to extend the library for animating things like filters, matrices, or other complex objects. With so much to love, I had to port it to Haxe eventually, right?
For the Haxe version, OpenFL support was a given, of course, considering that the original version was for Flash. However, I also wanted to be sure that all Haxe users might be able to take advantage of GTween in their projects, even if they they don’t use OpenFL or Lime. When targeting JavaScript, GTween uses the standard JS requestAnimationFrame API for timing. For other targets, it uses Haxe’s Timer class. I am open to adding support for more libraries that have their own timing mechanism too, so please don’t hesitate to open a PR with some additional conditional compilation if that’s something you’d like to see.
The GTween library has a number of sample projects that demonstrate how to use things. I made sure that live demos are available online so that you can see them in action without needing to compile them yourself.
Run the following command in a terminal to install GTween for Haxe:
haxelib install gtween
Read through the GTween for Haxe API Reference to learn how to use the library, and be sure to check out the source code for the samples in the links above.
Actuate gets the job done, but it’s API is one that I don’t particularly enjoy working with. It has at least one interesting feature that I like a lot, though.
Most properties cannot be read after an actuator is created, and I had to create a subclass to expose those. I have cases where I need to access things like the duration, and I’d prefer not to store it in a separate variable when I know that the actuator that I’m already storing has that information, but hidden privately.
When I need to store an actuator in a variable, I have to remember what purpose the type parameters of SimpleActuator<T,U> or GenericActuator<T> serve, and possibly even why those two classes have different numbers of type parameters. Or I can just set them to Dynamic. Either way, it feels like something that I rarely, if ever, need to worry about, so it’s extra busy work for little benefit.
On the other hand, one thing that I really like about Actuate, but GTween doesn’t have, is Actuate.update(). It lets you pass in arrays of start and end values, and a function that gets called on every update with an array containing the current values as a parameter. It’s main benefit is that you can set properties on an object that is fully typed, and this ensures that those properties cannot be removed by Haxe’s dead code elimination (DCE), if you use DCE.
Oh, I see… and I do use some of these “actuate-only” features, but I’ll keep an eye on GTween since I found it very interesting. And what about performance? Have you compared the two libraries?
Testing a particularly intense scene with both libraries using 5000 or more simultaneous tweens, GTween appears to be a bit slower than Actuate. However, the difference between Actuate and GTween is very small. Things like the number of display objects rendered in the current scene will have a much bigger impact on performance than the number of simultaneous active tweens.
Regardless, when I get a chance, I’ll try to see if I can optimize GTween a bit. It’s mostly just a straight port from AS3, so there may be some things internally that could be rewritten to be faster in Haxe.
Did you look at some of the other haxe tween engines specifically I seem to remember:
It is actually not that hard to manually create a tween in haxe, one nice way is with an iterator that increments using the ease equation then you just wire it to a timer.
There’s also OpenFL’s official port of the caurina.transitions.Tweener library from AS3 to Haxe.
I remember that one being pretty popular among Flash developers for a while. I think it was one of the first that refined the API for creating tweens to require less boilerplate than before.
I specifically ported GTween to Haxe because I have several old Flash games that I eventually want to get running on OpenFL, and they all use the AS3 version of GTween. It should save me some time if I can keep using the same tween engine and need only to convert the syntax to Haxe because the API is unchanged. Plus, like I said before, I like the GTween API better than Actuate in many ways, so it’ll be nice to have GTween as an option again for new projects going forward.
Since we are on the topic, I’ll give a shout-out for GSAP which is completely free to use now. I do not believe the license would allow for a port to Haxe, but generating externs would give you a powerful option for the JavaScript platform. This (formerly TweenMax/TweenLite) was one of my favourites back in the Flash days, along with Fuse Kit.
When you say “compatibility layer” I hear “externs”, which would be completely legal and possible. You are just limited to targets supported by GSAP.
