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]

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"

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

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

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.