Stephane Hockenhull

sorry I gotta go now, nice chat.

yeah

" Integrals 'n' stuff "

Because friction is a "surface under the curve" type of math.

You probably should, just in case you decide to increase the fixedupdate because computers can't cope later down the project, so you don't have to re-tweak all your values.

Either you limit the catch-up updates, or display a "catching up..." overlay

yeah.

LOL

How long you could play depended on how fast your computer was. The slower the computer (the bigger the delta time) the more you could play before it rounded down to nothing.

Morrowind had that bug where after around 80 hours of play, fast computers had too small of a deltatime and animations stopped working due to rounding down updates to nothing.

this.remainingTime -= physicsTimestep;

You update bool variables with the button states. And your update() looks at those booleans.

The browser process those between animate calls., so they're kind of "once per frame"

including inputs.

yes

right. As long as your other systems don't affect the outcome you're good.

and so on...

ack, that last line was supposed to be physics(4) physics(4) physics(4), then physics(4)physics(4)

You can also do physics(4) physics(4) so for a total of 12ms (went over but it's okay), and next time if you get another 10ms (total of 20ms) you then go physics(4) physics(4)

Only ever call whole timesteps.

If you have 10ms you call physics(4) physics(4) so for a total of 8ms, and next time if you get another 10ms (total of 20ms) you go physics(4) physics(4) physics(4).

I cannot recommend a specific frame rate as this depends on physics complexity and your minimum system requirements, Javascript engine performance, etc. You'll have to try it out for yourself as you develop your game. But I will recommend using a delta time variable parameter to the physics update function so you can change the fixed time-step. So long as it's consistent between computers you'll avoid a lot of [bug that only happen on fast or slow systems] situations.

@DMGregory I was just adding that :) In general for numerical stability I prefer to calculate physics at a fixed rate. @Ryan Say you decide to run your simulation at 100Hz (10ms) and you have a 1.003 second delta, you end up running your update physics loop 100 times. In pseudo-code: new_time = now(); while(sim_time < new_time) { Update(10ms); sim_time += 10ms; }

Already got mine :D

#JustElderScrollsThings

@DMGregory Are you editing your answer? I'm going to revert my changes if you're not mid-edit.

I think the table is off by one. when you reach 16 777 216 you can't add 1 anymore, gotta add 2... or am I confused again?

I usually just do my physics in fixed points. Only doing the square root in float after subtracting in fixed points.

Like, if I made a 2D game with at least 8bit of pixel fractions (like old 8bit/16bit games used in their physics) I could walk 65536 pixels either directions before I don't have those 1/256th of a pixel anymore.

Because usually the [ smallest unit value of concern ] scale is what matters the most in practical terms. Even though in practice it gets a lot worse due to other rounding.

I'm used to think of it in equivalent fixed-points precision for a given distance unit rather than a given exponent.

Now that I re-read it, your numbers were right.

ooooh okay. put that way yes

Or rather, it's +/- 2^-25 error

I think it's 2^-24 error

I'm trying to figure out if it's 2^-24 error or 2^-25 error...

darn float implicit bit is confusing

you were one too low in your answer...

I was one too high here in the chat :P

Not 2^23 numbers

So it's ` we have 2^24 representable numbers, spaced 2n−24 apart.`

that's why it's 24bits of precision

no, you're right. 2^23 stored you can still add 1