How to force the physics engine to run?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By uzimonkey

I’m making a game that has no dynamic bodies, the only physics nodes are StaticBody2D, KinematicBody2D and Area2D. To keep smooth animation and responsive controls, I’m moving these bodies in _process and it seems to be working fine. In Godot 3.1 alpha move_and_slide even works correctly in _process, so everything is very smooth looking and responsive.

The problem that overlaps are not running until the next frame at best. If you take a look at the main loop, it’s iterating the physics engines to catch the physics simulation up to real time, but it’s doing it before _process meaning it’s detecting overlaps from last frame’s movements.

I realize running a physics simulation with a varying delta can result in unpredictable or undeterministic results, but in this case I don’t care. I’m basically only interested in area overlaps and want them to happen much more responsively than they are now. As it stands right now if someone runs the game on a 144Hz monitor they could be waiting 2 to 3 frames before that 60Hz physics timer ticks over and even though that’s a fraction of a fraction of a second, that’s just a bit of lag that doesn’t need to exist in a game like this. I could crank up the physics frame rate but even then at best there will be a 1 frame lag between action and reaction.

So what I’m really looking for is a way to manually run the physics engine myself at the end of _process. I’ve poked around in the source code and the functions that would need to be called don’t seem to be exposed to GDScript. I’m thinking this might be possible though since this is a common feature used to implement multiplayer games with synced physics.

You’ve tried Physics FPS in ProjectSettings under Physics/common?

lavaduder | 2019-01-04 14:16

That’s not the issue. The issue is that the main loop calls physics first and because of this you have two bad options:

  • Do movement in _physics_process. However, there’s no way to guarantee that _physics_process will run every frame, meaning movement can be quite jerky.
  • Do movement in _process, which produces silky smooth movement without fail but doesn’t allow you to check for collisions on the same frame as movement meaning any response is delayed by one frame at least.

It would be much easier to just call the physics engine and tell it determine overlaps at the end of the idle time. That way movement is always silky smooth and responses to overlaps are not delayed by a frame.

Barring this, I need a way to dynamically adjust the physics FPS to the refresh rate of the monitor and use vsync. Since there are no bindings to force the physics engine to run, apart from modifying the engine this is what I’m going to have to do. It has to be dynamic because there is a wide range of monitors on the market now, you can’t just assume the player will be on a 60Hz monitor.

uzimonkey | 2019-01-04 15:48