im trying to achieve camera movement that deceases in speed the closer the camera gets to its optimum position, above the player model. the obvious way to go about this is by subtracting a percentage of the remaining distance to cover from the camera's position:

camera.x -= .02 * (camera.x - intended.x);
camera.y -= .02 * (camera.y - intended.y);

this is nice and smooth, but the camera would move around faster on faster hardware, and just multiplying the percentage by time_step doesn't work because the problem deals with exponents(and subtracting a percentage twice as big with half the frequency yeilds different results). Any ideas on how to factor time_step into an exponential increase or decrease?
thanks people!

btw this problem pops up in several places in my project, the camera scenario's just the easiest way to explain it.

camera.x -= .02 * (intended.x - camera.x) * time_step;
camera.y -= .02 * (intended.y - camera.y) * time_step;

You may need to increase the 0.02 to get the old feel(probably about 0.1), but
it will now be stable across all hardware speeds, once you found that number for yours.

Thanks for your reply evilSOB

But the point of the question is that just poking time_step in DOESN'T work, because subtracting a percentage of a number once a second (for example) produces a faster decrease than subtracting a quarter of that percentage four times a second, right? So normal time_step doesn't work.

I think the answer would have something to do with multiplying a power by time_step, but i don't know how it would work. I'll keep thinking but any suggestions are appreciated.

no, why do you think so? simply multiplying time_step works fine.

Because:

(assume target camera x position is 0, and assume camera.x is twenty)

faster machine: time_step = 4:

camera.x -= .02 * (camera.x - 0) * 4;

wait(1); // camera.x now equals 18.4

camera.x -= .02 * (camera.x - 0) * 4;

wait(1); // camera.x now equals 16.928

camera.x -= .02 * (camera.x - 0) * 4;

wait(1); // camera.x now equals 15.57376

camera.x -= .02 * (camera.x - 0) * 4;

wait(1); // an amount of time has passed. camera.x now equals 14.3278592

final camera.x after one second on faster machine is 14.3278592



slower machine: time_step = 2:

camera.x -= .02 * (camera.x - 0) * 2;

wait(1); // camera.x now equals 19.2

camera.x -= .02 * (camera.x - 0) * 2;

wait(1); // same amount of time has passed. camera.x now equals 18.432

final camera.x after one second on slower machine is 18.432

hence decrease of camera.x is greater on faster computers if you use

camera.x -= .02 * (camera.x - 0) * time_step;


well i was wrong when i said that a faster machine would produce slower camera movement (mostly due to the painfully noobish assumption that time_step reflects the number of frames that occurred in the last second), but the point remains the same. Because i'm dealing with exponents the usual means of implementing time_step doesn't work. I've really got some thinking to do. Perhaps i should start a new thread, as ive made such a mess of this one? Nah ill just correct the first post

camera.x += (target.x - camera.x) * pow(reductionpersecond,16/time_step)

target.x is the target camera position (0 in your example).
reductionpersecond is the percentage of the distance that should be covered each second.

great!!! i knew there must be something! thanks so much bigM you are a genius. ill try it out now, it looks correct...

one question though, out of curiosity..

where does the 16 come from? i thought a tick was a sixteenth of a second, but this formula has nothing to do with ticks, or does it?

It seems ventilator is correct, with precision being a consideration.

Try reversing 2 and 4 (above in example calcs).

nooo! bigM's formula doesn't seem to work, and I have no idea how to adjust it because i don't know how it works because it has that mysterious 16 in it!