Conflicting explanations of _physics_process

In this lesson, I wrote that _physics_process has a fixed delta value. In other words, it does not depend on the framerate. Whether the framerate is 10 or 60, the physics_process's delta value is the same, and the character's movement will stay constant.

There's a bit I wrote that's important:

if your game slows down, the physics can also slow down as a consequence.

Imagine exceptional cases:

1. You have a 0.2 seconds freeze at some point for whatever reason, e.g. another program taking priority over the game on Windows, your physics calculations can't follow, and it takes 0.2 seconds to get the physics update: your character will move, by default, for 1/60 seconds worth of time.
2. If the player's computer is too slow to handle your game's physics, and the physics can update only 10 times per second, the movement will appear 6 times slower than it should.

This is independent of the number of frames rendered in that amount of time, that may oscillate. So, again, this is framerate independence.

In practice, this rarely happens. You'll have minimum requirements for the game, and physics can run in threads separate from the main game loop's thread, which helps to keep everything smooth.

It will run 60 times per second by default, but on a slower device you could take it down to 30 updates per second.

Here is the explanation from the official docs for completion:

Use _physics_process when one needs a framerate-independent deltatime between frames. If code needs consistent updates over time, regardless of how fast or slow time advances, this is the right place.

I hope it helps!