Ashley - something I've been missing a lot is the cosp, qarp and cubic expressions from CC. I had an idea though that could be even better, but I don't know if it would work - an expression like interp that would take is many parameters as you give it for as many points of interpolation wanted.

So interp(a,b,c) would be cosp, interp(a,b,c,d) would be qarp, interp(a,b,c,d,e) would be cubic, and anything past that would get you extra points, such as interp(a,b,c,d,e,f) would be five point interpolation.

Could this be done? There have been a bunch of times I've wanted interpolation past 4 points, and this would allow as many points as the user wants without needing a separate expression for each one.

I asked this question waaaay back when CC was first started, and the answer was a no. The problem is that once you get past a third point it tends to complicate things almost exponentially.

I've been wondering why we didn't get a cosp. Could be that even that is a bit too much for the jscript.

The real question would be do you need interpolation or is approximation sufficient? Interpolation would indeed be quite expensive for a large number of control points. With approximation, however, you'd be able to string together several cubic b-splines for as many points as you'd like with relative ease.

It depends on the accuracy of the approximation, I suppose. I'm not familiar with approximation techniques in this circumstance so I don't know if they are sufficient or even if the level of fidelity of the approximation can be varied.

I'm trying to recreate the effects shown in this video of the bouncing and flying enemies as well as the trajectory of the boomerang, all of which I used cosp/qarp and cubic for originally.

Wow, people are still using the extra expressions plugin?

There is EaseTween behavior, which contains numerous interpolation methods, but it's more for tweening purposes. Figure you could use it for boomerang pathing, just keep the start and exit angles in mind.

Would be great if there was a way to insert such functions into a project, the plugin SDK is an awkward way. Not everyone can churn plugins out like a certain rex!

After looking into lerp and playing with its parameters for a while I believe that you can get all the results that you need just from it.

For example for ease-out you use:

lerp(start, finish, time_counter ^ 2)

For ease-in you use:

lerp(start, finish, time_counter ^ 0.5)

You just need to make sure that:

1) your time_counter starts in 0

2) you increment it by some amount depending on how fast you want the movement to be (0.1 each tick its a fairly fast movement, so I normally use 0.05)

3) your end condition is always time_counter = 1 (or greater).

Finally, if you you you are looking for a higher-level solution you could always use the tween plugin as already suggested.

I really like the art style of your game. Hope this was helpful :)

When I've use lerp to move sprites it seems to have built in "slow down" toward the end which is great. If I wanted this "slow down" at the beginning and the ending would I use qarp? (or your lerp(lerp(a,b,t), lerp(b,c,t), t)). I tried it when zooming out the layout and it doesn't seem to work like I expected...still feels like a regular old lerp.. since it starts zooming fast then gradually slows.

Set Layout scale to lerp(lerp(LayoutScale,1,0.5*dt), lerp(1,4,0.5*dt), 0.5*dt)
[/code:1tivcegf]
a=LayoutScale (which starts at 1.3)
b=1
c=4 (wasn't sure how steep to make the curve)
t=0.5*dt

When I've use lerp to move sprites it seems to have built in "slow down" toward the end which is great. If I wanted this "slow down" at the beginning and the ending would I use qarp? (or your lerp(lerp(a,b,t), lerp(b,c,t), t)). I tried it when zooming out the layout and it doesn't seem to work like I expected...still feels like a regular old lerp.. since it starts zooming fast then gradually slows.

> Set Layout scale to lerp(lerp(LayoutScale,1,0.5*dt), lerp(1,4,0.5*dt), 0.5*dt)
[/code:f8psydme]
a=LayoutScale (which starts at 1.3)
b=1
c=4 (wasn't sure how steep to make the curve)
t=0.5*dt

The "built in slowdown" comes from the use of lerp you are using, a is the variant in your case, so you have a "suite arithmétique" (not sure of the english term for that), that will go slower and slower towards the point. (it shouldn't even reach it, I never understood why people are using lerp like this)

To be exact, lerp(a, b, x) return the value between a and b, corresponding to the percentage (reminder of math: 1 = 100%) x, from a to b

lerp(a,b, 0) will return a, lerp(a, b, 1) will return b, lerp(a, b, 0.5) will return (a+b)/2.

The intended use is to make x varie (generally from 0 to 1, but it can go over that), for your zoom, you can have lerp(min value, max value, zoom percentage), and make the zoom percentage varying from 0 to 1 or 1 to 0 as you want it.

The qarp will be the same logic, but applied not in a linear fashion (a quadratic one, which I think means that a and c will be min and max, but b will be affecting the way it evolves with each values of t)

qarp (a, b, c, 0) will return a, qarp(a, b, c, 1) will return c, qarp (a, b, c, 0.5) will return ((a+b)/2+(b+c)/2)/2 = ((a+c)/2+b)/2 I think