#### Archived

This topic is now archived and is closed to further replies.

# Consistent Acceleration for Varying Framerates

This topic is 5700 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi all, I have this situation where my character has a velocity. I'd like my character to slowly decelerate as frames progress, after I release the pressure on the joypad. Currently, I'm doing this by multiplying her velocity vector by .95 every frame, so that as frames progress, she slows down. The problem with this is that this solution is frame-dependent -- if there is a high frame rate, her velocity will slow down much quicker and she won't slide far accross the terrain. If there's a slow frame rate on the other hand, her velocity will slow down more slowly and she'll slide far. I hope this makes sense... you can download the demo of what I'm trying to accomplish and check it out right here. Camera acceleration is based on the same premise, so it has the same problem. Couple tips for this demo: She is joystick controlled, so you need a DX compatible joystick plugged in. Press 's' to toggle the shading mode (this varies the framerate, so you can see what I'm talkin about) Press 't' to texture the terrain. I'm suddenly wishing I had taken more physics classes... Thanks to anyone who might have a solution to this! [edited by - Riskbreaker on May 5, 2003 2:57:37 AM]

##### Share on other sites
You need to make your calc''s time-based instead of frame based. This is a little tricky to do because of just adding an amount to your values, you have to interpolate that amount by the time since the last update. By way of example:

If you determine that the character accelerates at .75 m/s/s, then you have to set up a linear interpolation that says something likes:

AccelThisFrame = TimeDifference(Now-LastFrameTime) * .75
LastFrameTime=Now

This way, so long as you have at least 1 frame/second you can get consistent acceleration.

Last thing to go through a tortoise''s mind before it hits the ground at 40mph? "D3DXVec3Add (Tortoise.Pos, Tortoise.Delta, Tortoise.OldPos"

##### Share on other sites
Something to add to what SoaringTortoise described:

It''s worth averaging the elapsed time over a few frames - that helps to smooth things a lot more. The elapsed time for a single frame describes the time taken by the PREVIOUS frame, the CURRENT frame might have different characteristics (i.e. a harddisk access etc), averaging means you smoothly pick up on "trends" in the framerate rather than jerkily/immediately responding to changes. Also spikes sometimes only happen for one frame (the previous frame).

--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

##### Share on other sites
Well, i''m interested to hear the answer too. What he describes is "friction", not the standard velocity/acceleration problem. If P is the position, V the velocity and A the acceleration, one can generally do:

P = P + V * dt
V = V + A * dt

But here he''s trying to do V = V * F

and F has to be a function of dt... 1.0 meaning no friction, smaller values like 0.95 increasing the friction; a value of 0 would make it impossible to move at all.

What should the value of F be ?

Y.

##### Share on other sites
There are two parts to your problem. The first is determinging acceleration.

Since friction affects velocity, and it does so at a predictable rate, we can write a function to get the acceleration. Let''s say for example we want acceleration to equal -velocity*.1;

With the method I''m about to use, this would mean that the object would slow to a complete standstill in 10 seconds. However, this actually won''t happen since we will constantly update acceleration.

How would this work? For the sake of simplicity, let''s say our game runs at one frame per second, just so that we can overlook timing issues for now. Initially our velocity is 10. Well, then our acceleration is going to be -1. If we''re going to overlook timing, we''ll have the basic function of:

velocity += acceleration;
position += velocity;

Well, then our velocity is set to 9. Next frame, or acceleration is -.9, so our velocity ends up being 8.1. Next frame, acceleration is -.81, so our velocity is 7.29 (I think. Did it in my head). Well, we can see that basically what''s happening is that our velocity is going to decrease, and the decrease is going to be related to the velocity. Well, now that we have the basic function, this is simply a timing issue.

What you need is a timing method, and then the velocity will work itself out just fine from the acceleration. Furthermore, as you stated, you need a consistent framerate. So how do we get a consistent timing method? Well there was just such a discussion earlier in this forum a few days back. Let me get ya the link:

http://gamedev.net/community/forums/topic.asp?topic_id=152750

Just a word of caution. The post was started by Neen10do, but his method is not what you are looking for. I have a pretty good explanation ( I think) on a consistent method, so read on in the post.

--Vic--

The future of 2D game development:
Flat Red Ball

##### Share on other sites
Thanks so much for the replies... the general ideas for attacking this problem seem to be the same. Thanks for giving me heads up on where to start! Simon, thanks for pointing out the idea on averaging frame values... that solved a previous problem I was having with camera jerkiness.

1. 1
2. 2
3. 3
4. 4
Rutin
13
5. 5

• 24
• 10
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633695
• Total Posts
3013373
×