So,
from the manual, time_step is the smoothed version of time_frame, which is "The duration of the last frame cycle in ticks, i.e. sixteenths of a second". If you want to work with seconds you must always divide time_step (or time_frame) by 16.

I have not tried the equation myself but it should work. I noticed a bug in what I wrote: reductionpersecond is not a percentage, but a value between 0 and 1, maybe that's why it didn't work out for you.

One other thing I don't get from your example is the higher time_step for a faster computer: a large time_step means a larger lag between frames, which translates to a lower framerate. Slow computers have lower framerates, fast ones have higher rates.

Ask if you want me to explain the equation more in detail.

Damn, a stupid mistake:

it should be

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

(with reductionpersecond between 0 and 1)

Now it should work.
pow(reductionpersecond,time_step/16) is the corrected reduction factor; if a frame lasts 0.5 secs the factor will be the square root of reductionpersecond, a second frame of 0.5 secs will have another decrease by the same factor, which means that after two frames (1 second) there will be a total reduction of factor1*factor2 which equals reductionpersecond.

By the way, after you get it working, maybe it's best to work with time_frame instead of time step because that will give you the exact elapsed time from the previous frame, not a smoothed time. I think it may prevent some jitter if the fremerate suddenly changes.

Anyway, this is just dry talk. Like the equation, I did not test it.

Let me know how it works for you.

hm... i never had problems with simply multiplying the time_step. you will reach the target in the same time. of course there will be inaccuracies and the curve will look a bit differently but this never was noticeable as a problem to me. you should also make sure that the time_step never causes the factor to be 0 or bigger than 1.

it would be interesting to have some comparison tables or curves of both methods. at a first glance i can't really imagine what the pow solution does. it seems to be wrong to me.

edit:

simply multiplying time_step:

i don't see any problem here? you could say "hey, the error is 200% after the time span" but both are very near to the target already and the difference shouldn't be noticable by anyone.



if i understand it correctly the pow method takes less steps with a higher framerate. it won't work at all.

Sorry, only got to reply now:

There was yet another small mistake in my equation, final version now:
camera.x += (target.x - camera.x) * pow(1 - reductionpersecond,time_step/16)

I simulated three different timesteps with both methods. Mine gives the exact same results for all timesteps, but I guess it may be slower because of the use of pow. Yours has small precision errors but I'm not sure if they have importance at any scale. I think it will ultimately depend on the situation.



Please let me know what you think.

haha two titans are slugging in out in my thread!!

after i found that bigM's thingy still didn't work (and now i have to go make the "1-" change) i smacked together a third method, which is hideous to look at, and slow, but seems to do the job:

camera.x = (pow(sqrt(abs(camera.x - target.x)) - (time_step * .5),2) * sign(camera.x - target.x)) + target.x;

(Was missing bracket, fixed now)

just thought i'd post it for the sake. its based on the parabola y = x^2, where x represents time and y represents the camera's position relative to target.x.

so yea. if bigM's works now i'll go with that.

blast of course it doesn't! with or without a "1 -" the camera is stuck at target.x constantly! ahh well at least i have a backup plan

i dont get how it's meant to work.. pow(reductionspersecond,16 / time_step) seems to always yeild a number very close to one. so the camera appears stuck over the entity...

Damn... I'd better try this with real code, rather than just theoretically.

(By the way, how much are you using for reductionpersecond?)

Best luck

why overcomplicate things if the difference is only visible as a small aberration in some excel graphs? nobody will notice this in your game.

if your frame rate isn't fixed you will have such small inaccuracies in other areas like physics too. i wouldn't bother about it.

Yeah, I agree with you ventilator.

I guess that if neither approach is working there is probably some other problem in the code that needs to be solved.

I did spot a problem in Chaeon's implementation: pow(reductionspersecond,16 / time_step) should be
pow(1-reductionspersecond,time_step/16)

(notice the '1-' and the inversion of time_step/16)

!!? my thingy doesn't have a sixteen or a 1-, its a completely different way of doing it. its converting the curve into a steady decrease, altering it by subtracting time_step * a_number and the converting it back. i think that this is the best way to go about the thing, as steady increases and decreases in values are far easier.

and yes, perhaps slight differences in the camera could go unnoticable, but the camera was only an example i used to demonstrate a problem in far more touchy parts of the code.

hey its off topic, but i wrote a quick function at the top of the script that i've been using in situations like this, and id just like a professional view on it, just to see if im in the right direction in terms of programming's "layers of abstraction", y'know? writing reusable code. is this a common method?

near beginning of script:

function closesttozero(element_a,element_b)
{
if(minv(abs(element_a),abs(element_b)) == abs(element_a))
return(element_a);
else
return(element_b);
}

its handy for things like

speeds -= closesttozero(speeds,20 * time_step * sign(speeds));

would you say my methods were too slow?