Slowing a ball in a variable framerate
Author
I want to slow my bouncing ball by reducing its speed by 90% every second. So, I'd multiply the velocity by 0.90 every second, or .9486 every half second, etc. The problem is, the framerate is variable (as the game is time-based, not frame-based). So how do I figure out what to multiply the velocity by each frame, based simply on my goal (90% every 1.0 seconds) and the duration of the last frame?
Is there a solution that doesn't involve calculating an exponent (as I'm sure that would slow things down...isn't the exp() function rather slow?)
Quote:Original post by KulSeran
assuming your frame timer returns fractions of a second,
speed = .9 * speed * frame_dt;
This is exactly what you want. I feel that it's always best to pass in the time step instead of hard coding it to a certain value (even if it will always be that certain value). It is much more robust that way and you can even do some things like scale it to trivially speed up or slow down the timestep (useful for debugging).
Author
No, this isn't right.
At the end of a full second, I want my speed to go from 1 to 0.9.
Let's assume that the last frame took 1/2 a second.
So, according to the given equation, speed = .9 * speed * frame_dt;
OR
speed = .9 * 1 * 0.5 = .45, which is not 0.9.
The change in speed here is not linear, which is the problem. I want my speed to reduce to 90% every 1 second, NOT .1 every 1 second. So if the speed is 3, I want the speed to be 2.7 after 1 second, 2.43 after 2 seconds, and so on.
At the end of a full second, I want my speed to go from 1 to 0.9.
Let's assume that the last frame took 1/2 a second.
So, according to the given equation, speed = .9 * speed * frame_dt;
OR
speed = .9 * 1 * 0.5 = .45, which is not 0.9.
The change in speed here is not linear, which is the problem. I want my speed to reduce to 90% every 1 second, NOT .1 every 1 second. So if the speed is 3, I want the speed to be 2.7 after 1 second, 2.43 after 2 seconds, and so on.
You guys are kidding, right?
He wants it to slowdown to 90% after ONE second. So what happens with your formula after half a second? .9*.5, so suddenly the speed is down to 45% instead of 94.86%. That's exactly what he DOESN'T want.
Is there a specific reason to use 90% instead of a constant deceleration (which would be a lot easier and linear)? speed -= speed*.1*delta_time would be easier and should look right for small timesteps. Else I foresee integration to create mathematically correct results.
Which is btw. a common problem if you use completely unfixed time steps. Works great for linear movement but will create pretty different results otherwise (take the typical curve of a thrown ball, doing it in linear step with varying deltas means a fast computer will stick close to the curve, a slow computer won't and in an extreme case reduce the curve to a straight line). So either you will have to use more complex math or think about using fixed time steps to at least ensure consistent movement on all computers (but need to prepare for a situation where the computer can't keep up and has to either skip updates or switch to a larger time step to catch up).
edit: too slow again
He wants it to slowdown to 90% after ONE second. So what happens with your formula after half a second? .9*.5, so suddenly the speed is down to 45% instead of 94.86%. That's exactly what he DOESN'T want.
Is there a specific reason to use 90% instead of a constant deceleration (which would be a lot easier and linear)? speed -= speed*.1*delta_time would be easier and should look right for small timesteps. Else I foresee integration to create mathematically correct results.
Which is btw. a common problem if you use completely unfixed time steps. Works great for linear movement but will create pretty different results otherwise (take the typical curve of a thrown ball, doing it in linear step with varying deltas means a fast computer will stick close to the curve, a slow computer won't and in an extreme case reduce the curve to a straight line). So either you will have to use more complex math or think about using fixed time steps to at least ensure consistent movement on all computers (but need to prepare for a situation where the computer can't keep up and has to either skip updates or switch to a larger time step to catch up).
edit: too slow again
Whoops.
Typed faster than I thought.
Trienco is right.
At the very least it should have read:
speed -= .9 * speed * dt;
thus making the speed 1/10 of the origional at the end of a second.
But forgetting that, you do need to take the oposite side of the percent
so the speed -= .1 * speed *dt; to reduce it to 9/10 at the end of a second.
Unless I managed to forget something else... so sorry bout that.
Typed faster than I thought.
Trienco is right.
At the very least it should have read:
speed -= .9 * speed * dt;
thus making the speed 1/10 of the origional at the end of a second.
But forgetting that, you do need to take the oposite side of the percent
so the speed -= .1 * speed *dt; to reduce it to 9/10 at the end of a second.
Unless I managed to forget something else... so sorry bout that.
You could calculate the speed at a fixed time step(like 60hz) and interpolate.
mult=ln(.9)/60
while(dt > 1/60th of a sec)
{
speed=speed*mult
}
speed_est=speed-speed*(1-mult)*dt*60
[Edited by - kiniport on December 16, 2005 2:53:44 AM]
mult=ln(.9)/60
while(dt > 1/60th of a sec)
{
speed=speed*mult
}
speed_est=speed-speed*(1-mult)*dt*60
[Edited by - kiniport on December 16, 2005 2:53:44 AM]
I missed that subtraction as well. I was more concerned with showing the variable time step in there.
The formula I would use is:
speed += decelleration * speed * fTimeStep;
where decelleration is -1.0f
The formula I would use is:
speed += decelleration * speed * fTimeStep;
where decelleration is -1.0f
I believe this is what you want:
new_v = pow(.9, t) * v;This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
