The equation of movement underneath fixed acceleration is:

$$vec p (t) = vec p_0 + vec v_0 cdot t + frac {vec a} 2 t^2$$

So if you did not have your drag, you might modify your code like so…

if(button_pressed)  vel_x = run_speed;
else               // TODO //

pos_x += vel_x * dt;
pos_y += vel_y * dt + 0.5 * gravity * dt * dt;

vel_y += gravity * dt;

Note that we add gravity to the rate after computing the place, in order that we do not double-dip and depend gravity twice in our place calculation: as soon as by itself, and as soon as inside the rate.

To convert your constants out of your outdated time step referenceTimestep to the brand new one dt, you’d simply multiply them by the ratio:

run_speed = reference_run_speed * dt / referenceTimestep
gravity = reference_gravity  * dt / referenceTimestep

Unfortunately, including drag makes this far more sophisticated.

This form of exponential drag has the shape:

$$start{align}
vec v (t) &= vec v_0 cdot b^t
frac {d vec v(t)} {d t} &= vec v_0 cdot ln(b) cdot b^t
finish{align}$$

Where $ b $ is a braking ratio fixed, describing what fraction of the rate ought to stay after one second. If it is the one factor appearing on velocity as above, then we are able to combine that simply superb.

$$start{align}
frac {d vec p(t)} {d t} &= vec v(t) = vec v_0 cdot b^t
vec p(t) &= frac {vec v_0} {ln (b)} b^t + vec c = vec p_0 + frac {vec v(t) – vec v_0} {ln (b)}
finish{align}$$

But as quickly as velocity is altering in response to this braking ratio and a relentless acceleration resulting from gravity concurrently, issues get a lot extra sophisticated.

$$frac {d vec v} {d t} = vec a + vec v_0 cdot ln (b) cdot b^t
vec v(t) = frac {vec a cdot e^{b^t} cdot Ei(-b^t)} {ln b} + vec ccdot e^{b^t}$$

This is in response to Wolfram Alpha. That $Ei$ there may be the Exponential Integral, a kind of nasty transcendental features we normally should approximate by summing phrases from an infinite collection, however one not frequent sufficient to be included in our normal gamedev math libraries.

If we attempt to combine this to get a closed-form expression for our place, Wolfram provides up and simply leaves the integral unevaluated:

$$vec p(t) = int_1^tleft( frac {vec a cdot e^{b^s} cdot Ei(-b^s)}{ln(b)} + vec c_1 e^{b^s}proper)d s + vec c_2$$

So, approximation is your solely hope right here.

I’d say your finest wager is to compute place utilizing the kinematic equation for fixed acceleration as above, which assumes no braking impacts the rate over the time step. That’s incorrect, however it’s solely a little incorrect in case your braking is gradual and your timestep is brief.

Then you’ll be able to compute your velocity utilizing the integral above if you happen to really feel like utilizing a math bundle that allows you to compute the exponential integral. Or you’ll be able to approximate it stepwise:

if(button_pressed)  vel_x = run_speed;
else                vel_x *= brake_decay;

Where:

brake_decay = pow(reference_brake_decay, dt / referenceTimestep);

Again that is solely somewhat incorrect, and it is lots cheaper. Since good consistency with completely different timesteps is off the desk anyway, I’d say this can be a affordable compromise.