Determining how long it takes to easein and easeout

[Ivlivs]

When using easein and easeout, how do you determine how long the sprite will take to reach a specific point? The speed isn't constant, so it would be very tricky.

Let's say you want the sprite to cover 160 pixels in 0.5 seconds, easing out. How do I determine the time it would take to cover 32 pixels, 64 pixels, 96 pixels, etc.? Any help would be appreciated.

[drKlauz]

You can find formulas in <RenPy folder>/renpy/common/000atl.rpy

Code: Select all

    @renpy.atl_warper
    def easeout(x):
        import math
        return 1.0 - math.cos(x * math.pi / 2.0)

    @renpy.atl_warper
    def easein(x):
        import math
        return math.cos((1.0 - x) * math.pi / 2.0)

Tho there is chance you solving wrong problem. Why at all you want specific coordinates?

[Ivlivs]

You can find formulas in <RenPy folder>/renpy/common/000atl.rpy

Code: Select all

    @renpy.atl_warper
    def easeout(x):
        import math
        return 1.0 - math.cos(x * math.pi / 2.0)

    @renpy.atl_warper
    def easein(x):
        import math
        return math.cos((1.0 - x) * math.pi / 2.0)

Tho there is chance you solving wrong problem. Why at all you want specific coordinates?

I want those coordinates so I can show a character jumping from a lower point to a platform higher up. I need to know how long to hold the pause so that I can time the landing animation.

Regarding the formulas, do they work like this? t = 1.0 - math.cos(x * math.pi / 2.0), where t is the time it takes to clear and x is the distance in pixels?

[drKlauz]

Maybe try to combine jumping and landing animation in one animation, this way you can just tell renpy to do all calculations.

progress=1.0-math.cos(normalized_time*math.pi/2.0)
normalized_time is in 0.0-1.0 range.
progress usually same, but can go out of range when needed.
After progress calculated it is multiplied by (final-start) value to get current value delta.

https://www.renpy.org/doc/html/atl.html#warpers

To calculate x for current time, you need either solve some math, which can become pretty tricky pretty quick, or you can iterate over this function, supplying t in range of 0.0-1.0 with some small step, say 0.01, if progress close enough to your target value, then store this t for later use. This iteration should be done only once at init stage.

[Ivlivs]

Maybe try to combine jumping and landing animation in one animation, this way you can just tell renpy to do all calculations.

progress=1.0-math.cos(normalized_time*math.pi/2.0)
normalized_time is in 0.0-1.0 range.
progress usually same, but can go out of range when needed.
After progress calculated it is multiplied by (final-start) value to get current value delta.

https://www.renpy.org/doc/html/atl.html#warpers

To calculate x for current time, you need either solve some math, which can become pretty tricky pretty quick, or you can iterate over this function, supplying t in range of 0.0-1.0 with some small step, say 0.01, if progress close enough to your target value, then store this t for later use. This iteration should be done only once at init stage.

Timing the landing animation won't be an issue once I know when the sprite reaches the ground.

To reiterate, I have an animation in which a character clears 160 pixels in 0.5 seconds via easeout. Does the 0.0 to 1.0 range represent the proportion of the distance covered (for example, 0.75 represents 3/4 the distance?) If so, would the result be the number of seconds it will take? I could be mistaken here.

[drKlauz]

If you feed 0.75 into warper function it will return progress value when 3/4 of animation already played, this 3/4 is not necessary 0.75. Just use different values until you satisfied with result.

I still believe there is much simpler solution to this, like using image atl+transform with parameters, what will play jumping-flying-landing animations according to these parameters.

Perhaps someone else may explain/answer it better than me.

[Remix]

Warpers just modify the time, not any related distances (though the distance is calculated from the returned time, so it might appear to modify distance)... they take a float between 0.0 and 1.0 and return a modified float (also often between 0.0 and 1.0)

Why not just alter your ATL to use multiple warpers between the image states rather than doing the lot with just one warper?

[Ivlivs]

While I can't say I've solved it, I think it's basically linear except near the beginning (for easeout) or the end (for easein.) I did some animation tests to experiment, and I found that treating it as linear basically gave me the results I wanted.

I could be wrong, but I'll go with this for now.