Understanding _process and fixed_process()

Question

I know this is a common and simple question but I still have doubt about them. I don't know how to explain my doubt in a good way, it will be long and here's my doubt.

AFAIK, _process is called every frame. I understand fame as in animation, 24 frames per sec, 60 frames per sec etc. BUT how is the frame defined in this function? for animation, the frame rate is constant, does this apply to _process as well? what if the frame rate is not smooth like a drop from 60 to 45? does it matter or not? the frame rate is just an averaged figure, so maybe it doesn't really affect the update? Will it just update after the previous frame? So the update is in random time intervals ? Say I put print("123") in _process(), if the frame rate is constantly at 24 , the print statement will occur per 24 times in one second, am I correct? if the frame in _process() is not constant, it will just print the statement after the frame is finished, so there may be more or less than 24 printed statement ,am I correct? the frame doesn't need to be constantly changed, as human can't really feel the difference as long as the time interval is short, is this how it works?

So I guess fixed_process() is what I am thinking that the frame rate is constant?

Last question, if something cannot finish the calculation in one frame, what will happen? I have no idea whether I am asking a reasonable question or not.

I use this two function a lot, I think I can live with it without understanding it, but clarification is always good, I have trouble in understanding stuff that changes with time, may be some explanation using example in certain second and frame can help? I don't know how to google this question, if there is already a link that solves my questions, please show me. This is a long Q&A question :|

Answer 1

As far as I understand:

_process is executed once per frame.
_fixed_process is executed once per physic tick, which sometimes is not always the same as the framerate (but has to remain constant due to physics engine constraints). Some games even lower it to 30 fps to reduce CPU usage (then they interpolate movement in visuals).

_process framerate is ideally constant, 60 fps most of the time. But it can fluctuate for several reasons:
- Maybe your PC is very busy and can't maintain a stable framerate
- Maybe something in your game takes more than 1 frame to complete, so it causes a delay which makes FPS drop (after 1/60 seconds, Godot is still busy and has to drop the frame)
- Maybe the player changed options such as V-sync, which decides wether or not Godot will wait for the screen to finish drawing the frame before running the next

Reasons above can affect at which interval of time your _process is called, and will also affect the value of delta, which will be higher if framerate drops (because more time elapses).

_fixed_process, on the other hand, is always called with the same delta. You can visualize its time interval in the Profiler:

As you can see, the blue curve shows how long the frametime is, including the time Godot waits before drawing the next frame at 60 fps. It fluctuates a lot (because the OS is not precise enough to always sleep at 1/60 second), but as long as its below 1/60 seconds, the game will run smoothly. The screenshot was taken in debug mode so performance is poor and you can see a lot of bumps. The red line however, shows the fixed frametime, and it's constant. It always takes the same time, and if it can't, just drops the frame (you can see it doesn't run at the big spike).

Note: "fixed frame time" is the actual time limit for frames. If you want to visualize how long fixed_process takes to finish, you have to tick "fixed time". "idle time" is how long Godot waits before drawing the next frame, I guess. I don't know exactly how these values are computed, but I understand why they look like this on the graph.

Comments

In _fixed_process you can use the physics engine, in _process, you can't.

---

Yeah, there is that too. It's even more relevant when you know there is an option for running physics in another thread, so there is less synchronization to do.