JUMP_EASING

ID:2473242
 
Jun 2 2019, 8:45 pm
Resolved
Animation now supports a new easing value called JUMP_EASING which can perform a sudden transition instead of a gradual one.
Applies to:DM Language
Status: Resolved (513.1490)
This issue has been resolved.
currently, animate allows us to create keyframes by supplying new transform or pixel offset values. These will interpolate over the duration of the frame.

In some cases, we might want to use animate() to supply keyframe data so that pixel offsets and transform changes happen on either the first or last frame of the keyframe.

Currently, we can acheive this by breaking up the keyframe into two animate calls:

animate(src,time=5-world.tick_lag)
animate(pixel_z=32,time=world.tick_lag)


But for obvious reasons, this isn't ideal, as two different clients may have different tick_lag values. It would be better to supply an easing value that indicates that the value should not be interpolated, but rather instantly change at either the first or last frame of the animate() step, as though it were a keyframe:

animate(src,time=5,easing=JUMP_EASING|EASE_OUT) //the jump will happen at the last frame in the duration



animate(src,time=5,easing=JUMP_EASING|EASE_IN) //the jump will happen at the first frame and then there will be a 5 decisecond delay before the next step
Jun 3 2019, 7:41 am
Can't you achieve this already by supplying an animate step with a time of 0?
Jun 3 2019, 12:47 pm
It would require two calls for the behavior Ter wanted.

This is implemented now for 513 BTW. Waiting till I have a build number to close.
Jun 3 2019, 2:46 pm
In response to MisterPerson
MisterPerson wrote:
Can't you achieve this already by supplying an animate step with a time of 0?

Not exactly. Imagine a situation where client fps varies. If you want to hit the beginning of the last frame, you can't do that without knowing the fps of the client ahead of time.

This is why the easing value is better, because it does not care about the duration, It's just a curve that jumps from 0 to 1 at a fixed delta percentage.
Jun 3 2019, 2:51 pm
In response to Ter13
I don't understand how client.fps/tick_lag is a factor. The duration of animation steps is in deciseconds, which doesn't scale with client.fps.
animate(src, time = 5)
animate(pixel_z = 32)
animate(time = 5)
animate(pixel_z = 64)
// etc.

Still, one call is better than two.
Jun 3 2019, 2:57 pm
In response to Kaiochao
Kaiochao wrote:
I don't understand how client.fps/tick_lag is a factor. The duration of animation steps is in deciseconds, which doesn't scale with client.fps.
> animate(src, time = 5)
> animate(pixel_z = 32)
> animate(time = 5)
> animate(pixel_z = 64)
> // etc.
>

Still, one call is better than two.

Ah, I see what you are saying now.
Oct 16 2019, 12:09 pm
Lummox JR resolved issue with message:
Animation now supports a new easing value called JUMP_EASING which can perform a sudden transition instead of a gradual one.