How fast Timer needs to be to be the same worth in power needed as Process or Physics Process? Is better for each Unit having own Timer or Process or having one in the game that sends Signals every time to all Units?
#Timer or Process, many or one for all?
leaden shard
Process is called at each frame rendered, if your computer can render at 60 frames per second or render at 500 frames per second, your calls will all be called at the same frame ratio.
Physics is called at 60, unless you modify in the project settings.
It all depends, what your use case ? what are you building with timers ?
novel shoal
Process is called at each frame rendered, if your computer can render at 60 fram...
I do not understand, then, in the second case, will Process be worked 500 times?
I want Timers or Processes or Physic Processes for anything that requires happening over time.
leaden shard
- _process calls depends on your FPS, if you let the engine work at full speed and your GPU is strong enough, it will do a call per frame rendered in a second.
- _physics_process is limited into 60 calls per second.
- With timers you have full control.
novel shoal
1. _process calls depends on your FPS, if you let the engine work at full speed ...
What call, I do not understand it. "call per framle rendered in a second" is the first thing I udenrstand not. And please answer my question, will it be worked 500 times? Yes, I have full control but how expensive Process, Phsics Process and Timers are compared to each-other? Will I need one for each Node or one for all Nodes?
leaden shard
About the 1. _process calls deppends on your FPS (frames per second). If you have a strong GPU and your scene is not complex and you render 400 frames per second, your _process will be called 400 times per one second. But if you have a weak GPU or a very complex scene thats is rendered at 30 frames per second, the engine will call your _process function 30 times per second.
The expensiveness of each call depends entirely on your function, what you wrote to execute on _process. If you wrote a expensive function and put on _process, lets say your function take 50 milliseconds (ms) to finish, each frame will take rendering time + 50ms, this means your FPS will tank and be lower as 20 fps.
wheat fractal
I do not understand, then, in the second case, will Process be worked 500 times?...
This depends on your use-case. For a lot of things, the _process function will be a good go-to. You can use the delta parameter that gets passed to it to know how long it's been since the previous frame.
Timers are useful mostly if you want something to happen after a set time, or on set intervals. You can connect the timeout signal to a script to run code when the Timer finishes.
The _physics_process function is, as the name implies, better for physics. The consistent 60 calls per second makes the physics more reliable and not framerate-dependent, so you want to do anything that'll involve collisions and other physics in this function.
leaden shard
Here some resources you may find a better explanation: https://www.reddit.com/r/godot/comments/13pfwwc/when_exactly_do_process_and_physics_process/
novel shoal
I understood something. I will choose randomly Process or Physic Process, I still want to know how expensive they are compared to Timers and the other question.
wheat fractal
They aren't expensive themselves. As was said before, the expense comes from the code they run, not really the functions themselves. Why are you worried about how expensive they are?
novel shoal
They aren't expensive themselves. As was said before, the expense comes from the...
But, if I make a Timer ultra short, repeating, in order of making Process that runs slower to save power, if a Timer is tenth of a second, will it be more expensive than a Process? Yes, I understand it is about the code, I still tought it would be a lot about Timers themselves from my past experiences with programming, that is - Timers to be expensive as they are, on top of the code they run, so each Timer run costs Timer and code, while Process or Physic Process, maybe they do not cost or if they do it is significantly reduced therefore it is realistically just the code in their cost.
wheat fractal
I think I kind of understand your thought process. And while wanting to learn is good, I'm fairly sure the difference is negligible for a high-level program like this. I can't give you the answer you want, I'm sure someone could, but that's my response. It's not a big issue. If you run into performance issues, it'll basically never be the cause.
novel shoal
I think I *kind of* understand your thought process. And while wanting to learn ...
I understand. Then, the other question is, whatever I chose to work over time on repeat, should I put it on the Root of Main Node in the Main Scene and it calls all the other, possibly hundreds of Nodes, enemies, their own Nodes, what not, should it call all of them that need this Process over time or each of them should have own Timer or Process, and how much should I generally divide my code for each Node separately compared to puting it to some Node that has collection of Nodes in itself to control them, is it all of it also quite similar in cost? I can put Timers and Codes in Enemy, therefore each of them would have them, or in the Map, World, Game itself to control them, or I can further than in the enemy, put it into each Node that needs some code own Script and Timers or Processes. The one thing I assume is putting Physic Processes into own unit, not all of them to be controlled by the one and main Code in the game.
wheat fractal
In general, you usually want things to handle their own over-time code. If you want like, a global timer that activates things on a set interval, then you'd probably want an autoload with a timer, and then you'd want to use signals.
novel shoal
In general, you usually want things to handle their own over-time code. If you w...
Therefore it is not good having it in the Main Script and calling each of them through there-found code as: "get_node("")" or through Variable.
leaden shard
A Timer can be to run at _process or _physics_process, a timer is never 100% accurate, it cannot run while the engine is rendering or processing physics, a timer can only trigger when the engine is at the stage where a script can execute, otherwise it would run mid-rendering, causing the engine to execute scripts that could modify objects while they are rendered, causing some sort of race conditions or desynchronizations.
You need to profile what is your use case, you have 1000 units ? their own process is expensive ? Try to have a single manager unit to process it and send the modifications to its units. You could also divide the process on multiple frames, process only 300 units each frame. Or even multithread, either get the result on the same frame or the result on next frame, allowing it to execute even on the engine time, where scripts cant execute, but threads still can. Just care to control access on resources that can be modified by the engine.