This site is currently in read-only mode during migration to a new platform.
You cannot post questions, answers or comments, as they would be lost during the migration otherwise.
+2 votes

Between _process(delta) and _fixed_process(delta), which virtual function should be used to run intensive computations that happen as fast as possible, to save CPU and to keep the FPS high?

An example would be, regenerating the health of a player continuously.

# This?
func _process(delta):
    health = min(health + 5*delta, 100)

# Or this?
func _fixed_process(delta):
    health = min(health + 5*delta, 100)

Which one should be preferred for performance?

in Engine by (12,908 points)

As comment because i am not absolutely sure i didn't messed something up.
In my experience if you have a lot to do (even if it is physics related) fixedprocess leads to way worse stutters and FPS drops as process does.
Even if the docs say _fixed
process and integrateforces are the only way to interact with the Physics engine without blocking, everytime i did this the result was worse as if i did it in _process.

3 Answers

+2 votes

If health regeneration does not involve physics use _process(delta).

The _fixed_process(delta) should be used when physics has to be called every frame.

by (722 points)
+6 votes

fixed_process is constraint to your physic_fps which are default at 60fps.
This means that _fixed_process is called every 1/60 seconds => 0.016667s.
_process instead is called every rendered frame. This means that it's delta depends on the complexity of your scene and the speed of your computer. You should always try to use the _process function and correct calculations by using the delta value (as you did in your example). Only if you really need your calculation to be parallel to the physic than you use _fixed_process(delta).

by (333 points)
+14 votes

Just my 2 cents.

I would usually follow this procedure when picking between _process and _fixed_process:

  • Is the logic concerning movement of a RigidBody? Move to _integrate_forces or (better not) _fixed_process.
  • Is the logic concerning physics or direct space raycasts? Move it to _fixed_process.
  • Is the logic doing something that affects only the gameplay business logic? Move it to _fixed_process. Because:

    • _processis called before rasterizing the next frame, which means it is FPS-dependent.
    • _fixed_process is linked to the physics thread, which means that all the logic would execute just as often as object are moved.
    • If the calculation is taking too long in _fixed_process it would drop the physics FPS, while the GUI would be just as responsive.

      • That's actually a bonus -- If it lagged the screen FPS instead, it would let objects that are affected by that logic fall through, die (because of late regeneration), etc.
  • Is the logic only about drawing and showing stuff? Move it to _draw or _process as required.

    • This type of logic would never change values that are used by gameplay/physics logic, unless it is in change of user inputs, etc.
  • If none of the above rules matches, split the logic in parts, and try again.

    • E.g. You can split health regeneration + health bar update between _fixed_process and _process.
by (1,608 points)
Welcome to Godot Engine Q&A, where you can ask questions and receive answers from other members of the community.

Please make sure to read Frequently asked questions and How to use this Q&A? before posting your first questions.
Social login is currently unavailable. If you've previously logged in with a Facebook or GitHub account, use the I forgot my password link in the login box to set a password for your account. If you still can't access your account, send an email to [email protected] with your username.