next »

[the.M4DNESS]

Hello,

So I want move something with dynamic speed. It makes a well made feeling, when the moveing object doesn't behave unrealistic. I can do a "faster staring, and slowing arriveing" in this way:

speed = "the distance between the two point divide with a value";
direction = "the arreving point's position";

But how can I do the opposite of this? The "slower starting, and faster arriveing"?
Thanks the answer

BTW, do you usually using thing like this in your games?

And sorry for my english XD

[bateleur]

speed = "the distance between the two point divide with a value";
direction = "the arreving point's position";

But how can I do the opposite of this?

direction = destination point's position (as before)

speed = either...
* distance from the starting point divided by a fixed value
* or a fixed minimum speed if the above would give a lower value
* or the distance to the target if the above would overshoot

If you can't cache your start point from frame to frame or if you don't have a start point (you want to do this continuously) then replace "distance from the starting point" with some fixed constant minus the distance to the target point.

[Tycho Brahe]

Just do what you were suggesting in your original post but divide a number by the distance instead of dividing the distance by a number. That should work, although its not very physically accurate

[Aquin]

I don't understand why you can't simply use acceleration.  Add a constant acceleration to your velocity (up to a max velocity) and add that velocity to change your position. 

If this is for a clicky interface (for moving troops or something), I'm sure there's a way to deal with it. Figure out the distance it takes for the troop to slow down (just calculate it) and when it hits that distance from the point, begin deceleration.

[Zaphos]

In general, if you want to go between two points and play with the way it moves, one way is to use linear interpolation + an easing curve.

linear interpolation (aka 'lerp'): just do lerp(start,end,t) = start+(end-start)*t, and you move from end to start at constant speed.  t is the time variable.

easing: do the above, but 'warp' t before passing it to the linear interpolation function by passing it through an easing function.  So, posn = lerp(a,b,ease(t))  Depending on the easing function you use, you will accelerate in, out, or both ways.

I don't know what language you're using but you can probably find a nice set of easing functions for it, or adapt one from a different language -- here's a set ported  to C# by Renaud Bedard: http://theinstructionlimit.com/?p=401

[st33d]

I just played some of the results of the Flixel tutorials recently and they all had this fucking irritating feature of taking ages to actually get any speed up. Like they were stuck in molasses and then whipped away across the landscape uncontrollably, unlike every platform game I've ever played. I hope this isn't what you're aiming for.

I generally just use verlet integration:

Code:

// constants - though I tend to alter them for different surfaces, etc.
damping = 0.98;
gravityX = 0.0;
gravityY = 1.0;

// every loop
tempx = x;
tempy = y
x += damping * (x - px) + gravityX;
y += damping * (y - py) + gravityY;
px = tempx; // edited
py = tempy;

// add speed
addVelocity(vx, vy){
  px -= vx;
  py -= vy;
}

Generally when I need to have acceleration I'd just slowly ramp up the value going into vx.

[Zaphos]

You set but don't use tempx and tempy in that code example; perhaps you wanted px = tempx not px = x?

One thing to watch out for with methods like that is that the motion it generates is somewhat frame-rate dependent, so if you're using delta time-stepping you'll get inconsistent results at different frame rates.  If you know acceleration is constant over a time step, you can compute the exact answer instead (eg x+=v*dt+.5*a*dt*dt), which may be preferable.

[powly]

Or if you know the acceleration is changing linearly, you should be able to use the average of before the timestep and after the timestep, if I'm not completely wrong.

[st33d]

Edited my typo.

I'm well aware that it's framerate dependant. It's not RK4 after all, but it is on the other hand very fast and easy to manage. It simply depends on how complicated your simulation is. If you're doing something basic - use something basic.

[the.M4DNESS]

Great, thanks the answers! Especially to Zaphos!

[Tycho Brahe]

Or if you know the acceleration is changing linearly, you should be able to use the average of before the timestep and after the timestep, if I'm not completely wrong.

you could, or youcould use calculus, eg, if:
a = t^2

then

v = 2t

where a is accelleration v is velocity and t is time