![]() Sep 15 2013, 2:49 pm
|
|
If different easings were to apply, I think we'd want some way to say: Use the last animation stage, but apply these different var changes as well with this different easing. That'd be more general.
|
I like Darke's suggestion, it seems simple enough to work with.
Example: Ball bouncing to the right and coming to a stop. //First step is to make the ball travel to the right. With the two calls to animate() together, the ball would look like it's tossed to the right while bouncing a few times as it loses momentum. What I don't know is how you would apply rotation to the ball without messing up everything else, I'm already having trouble with that as it currently is. |
Rotation can easily be applied separately from pixel offsets, though I agree this could be a problem if you wanted to do several full rotations as part of the whole thing (and it won't play particularly nice with easing). The identity matrix is obviously not rotated, and a full 360° rotation is identical, so interpolating between them won't rotate. A full rotation requires at least three calls, so you can spin the atom less than 180° each time.
Ultimately I think animation will have some limits; a very complex animation would require a very complex setup to handle it, and that ultimately isn't workable with the KISS principle. I think easing alone is simple enough to add; I was leaning that way during the design process and built in the slack for it. Having different parameters animate with different easings and rates simultaneously is a whole other issue. |
I've gone ahead and added easing in 500.1208. Just add a named "easing" argument, and set it to one of the following:
LINEAR_EASING (default) SINE_EASING CIRCULAR_EASING CUBIC_EASING BOUNCE_EASING (includes EASE_OUT unless otherwise specified) ELASTIC_EASING (includes EASE_OUT unless otherwise specified) BACK_EASING These can be combined with EASE_IN and/or EASE_OUT via the | operator. |