What’s the right way to handle delta time in a 2D platformer game loop?

[EmilyZW]

I’m trying to get my head around the concept of a game loop in my 2D platformer prototype, but my delta time implementation feels off. When I cap the frame rate, the movement is smooth, but uncapping it makes everything feel floaty and inconsistent, like the physics are slipping.

[SamuelTJ]

I get it. When I run uncapped, the movement starts to feel floaty even though nothing obvious changed in the code. I finally found the culprit was using a variable delta time to push velocity and then integrating position in one go. With big dt the integration steps overshoot and the whole thing slides. Once I named and traced that delta time effect, the behavior made more sense.

[LaylaAT]

Then I tried capping to a steady 60 and kept physics updates in a fixed step. It was rough at first, but the jitter dropped a lot as long as the step was stable. Rendering looked fine, and I learned to separate the physics update from rendering.

[DonaldAG]

I went further with a tiny accumulator and a fixed substep loop, computing physics in chunks and drawing between steps. After that, the movement felt more stable even when a frame took longer than usual, though there were edge cases when dt spikes happened again.

[AbigailS]

Could the real issue be something else, like how input is read or how collisions are resolved, and not the loop itself?