I know the purpose of timedelta, to help you keep game speed consistent even when the fps changes. and I know that its the amount of time that has passed since last tick

I understand lerp(here.x,there.x,0.5). And why that would give you a nice ease out from one location to another. And I also understand how I can use ^timedelta in my own caps just based off this with no greater understanding

What I don't understand is the math logic behind using timedelta as an exponent

Supposedly this is how ashley did it in some example, and I tested it with unlimited and fixed frames and it seems to keep the speed consistent.

I just really want to understand why, mathematically, this should work. It makes no sense to me at all. If someone understands the math behind using an exponent, and how it creates the correct effect, id appreciate it. And just in case: no, I'm not satisfied just understanding That it works. I want to know Why it works

There really is no significance, its just that 1-0.5^timedelta, or 0.011((1-0.5^1.69306434690952e-002)approximately) is a good percentage to start with... as far as the ease in, and out goes.

That plus its easy to dial in speed by changing 0.5 to anywhere from .9 to 0.000005.

What does this do exactly? Interpolates based on timedelta? The lower the framerate the closer you are to one of points? If the lerp value from 0-1 doesn't change, then how does it ease in/out?

What does this do exactly? Interpolates based on timedelta? The lower the framerate the closer you are to one of points? If the lerp value from 0-1 doesn't change, then how does it ease in/out?

just think of it like lerp(a,b,0.5)

each tick it would go halfway to the destination.

as it got closer it'd be a lower and lower distance.

so it's a nice smooth slow down that looks like a cosine curve

Ok, I was thinking about two stationary points, with the 0-1 value being used to move, which is how I usually use lerp(). What wasn't made clear was that "here.x" is actually the sprite's own x. You should have said set "set .x to lerp(.x,there.x,1-0.5^timedelta)".

For this kind of movement like you want, I usually just do

set .x to .x+(abs(there.x-.x)/(somevalue*timedelta)).

yeah, I guess the confusion was thinking timedelta was an exact science. there's no way taking the nth root of something can give truly similar results to multiplying by some other random a/b.

so basically what you guys are saying is that they really won't run at exactly the same speeds when moving at two different framerates, even in a perfect world where you had a perfectly exact timedelta. so just come up with some random equation that seems to work, or use one you saw someone else use somewhere?