Note: delta will be larger than expected if running at a framerate lower than Engine.physics_ticks_per_second / Engine.max_physics_steps_per_frame FPS. This is done to avoid “spiral of death” scenarios where performance would plummet due to an ever-increasing number of physics steps per frame. This behavior affects both _process() and _physics_process(). As a result, avoid using delta for time measurements in real-world seconds. Use the Time singleton’s methods for this purpose instead, such as Time.get_ticks_usec().
I really don’t understand why we should use delta from process, instead of writing our own ‘delta’ from Time.get_ticks_usec() if this is the case that delta is not ‘stable’ sometimes. Maybe I’m getting it wrong. Does anyone have any explanation?
Well, using delta is just easier and will do the job for most cases. Like it’s written in the docs, if you need really specific measurements - use the Time singleton.
As a result, avoid using delta for time measurements in real-world seconds
I don’t know if it’s my English, or if I don’t exactly understand how delta works, but for me this basically means don’t trust delta (period)
Because if it says “avoid using delta for time measurements in real-world seconds”, this means avoid using delta at all. If it doesn’t work reliably for real-world seconds, then any other reason you’d use delta for would also not work reliably.
Yes, that’s what it means. But do you really need that increased precision at the cost of inconvenience? For most cases, delta will be precise enough that you won’t see the difference between the two and you’ll be fine working with delta.
E.g. When you’re making a 20 seconds timer for the creep wave in a tower defense game - delta will probably be fine, because it won’t really matter if it’s 20.00 seconds or 20.01 or 19.98 seconds.
But on the other hand, if you’re making a speedrunning game where every ms counts and makes a difference - you better make sure your timing is precise, then don’t rely on delta alone.
