I didn't found a fitting sub-forum so i post here. Feel free to move the thread. I made a neural net and trained it with genetic algorithms. I want to port this project to Godot now. It is important for me to run the simulation as fast as possible. It would be great if i could also turn the rendering on and off, but that part is not that important. So what i would like to have is that the mainloop runs as fast as possible, but acts as the game would run with 60fps, so as i would run the game with normal speed. That would save me alot of time while the simulation trains the neural networks. Is that somehow possible?

There are two handlers in each Node which are repetively called. One is _process(delta) and the other is _physics_process(delta). The first is (roughly) called for every frame rendered. The latter is called in fixed intervals which equal the configured (project settings) physics fps rate. By default this is set to 60 iterations/calls per second. But it can be changed in the project settings.

So you `_physics_process(delta)' does sound like the thing that you search. It is not a loop though but a handler that is called regularly and should finish at least until the next iteration takes place.

But perhaps I misunderstood what you wanted to tell us. It is also possible to use multithreading.

@Schorsch said: I didn't found a fitting sub-forum so i post here. Feel free to move the thread.

Indeed, I'd say this is the right place, in addition to categories we make use of tags on the forum. Should we add a tag for AI? Also feel free to request other tags in forum chat if any come to mind, though it should also be noted that we don't necessarily want to add too many.

@wombatstampede said: There are two handlers in each Node which are repetively called. One is _process(delta) and the other is _physics_process(delta). The first is (roughly) called for every frame rendered. The latter is called in fixed intervals which equal the configured (project settings) physics fps rate. By default this is set to 60 iterations/calls per second. But it can be changed in the project settings.

So you `_physics_process(delta)' does sound like the thing that you search. It is not a loop though but a handler that is called regularly and should finish at least until the next iteration takes place.

But perhaps I misunderstood what you wanted to tell us. It is also possible to use multithreading.

Yes and no. That is one part of two. I would like to get those methods called more often than 60 frames per second. But secondly, i want the parameter to be set to 1/60 of a second. So if i run my game normally, it should run with ~60fps, but for training my ai, that would take way too long. Basically, i want to simulate my game fast, so i don't have to wait, but the game should act as if it would run with normal speed. I think if i set the mentioned value to more than 60 calles per second, the physiccs get more precise but the game is simulated at normal speed. The physics system acts dependent of the time. That is normal behavior and wanted in most cases. But in my case, it is not. Maybe i can show what i want with some pseudo code: A normal game loop (simplified):

while(game_running) {
    update(time_since_last_frame); // normally around 1/60s
    wait_for_some_time();
}

And i want:

while(game_running) {
    update(1/60 second); // so the game acts as if it is run with 60fps, but it runs faster
    // wait_for_some_time(); so run as fast as possible
}

I have no idea if this will work, but you might be able to get the functionality you are looking for by calling idle or iteration on the MainLoop class.

I do not if you can manually trigger the idle/iteration functions and the documentation is a tad sparse on what they do. In theory you could then pass in the delta time you want and everything should theoretically update using the passed in delta time.

Because MainLoop is inherited by SceneTree, you should be able to use get_tree().idle(1/60) or something like that. I have never used it myself though, so I’m just guessing based on what I could find on the documentation.

Hopefully this helps :smile:

Sounds good but that doesn't work :/ if i call them, they return false, which i think means that i should/could not call them.

Does using _idle or _iteration work by any chance?

I’ll keep looking around and see what I can find. While I do not have a use case myself, I can see several cases where something like this could be useful so I’d like to know if it is possible for future reference.

Edit: Looking at the source code, it looks like that the function returns false when it fails an if check. Not sure if there is away around it though...

Well, I figured out how to simulate/speed up normal processes. You need to use idle in the MainLoop class and that will make the loop call _process on everything with the delta passed in. It seems the delta value passed in has to be a whole number or something, because using 1/60 doesn't appear to do anything, while 1 moves everything forward by a single second and 0.5 seems to work, but I think it is rounding it up to 1.

However, this method doesn't work for physics. I think maybe that is what iteration is for, but it doesn't seem to do anything with large or small numbers. I'll keep at it and see what I can do :smile:

Well, I think it is a bug. Using iteration does make _physics_process move forward as expected, but the actual physics within the game doesn't move any faster.

I opened a GitHub issue and have included the project I was using. Personally I think it is a bug, but maybe I'm just using it incorrectly. Either way, hopefully we'll know more soon!

Thank you for your investigation. I hope that we can solve this :)

3 years later

@Schorsch @TwistedTwigleg Did you find a solution for this? I would be very interested in it, for Neural Network training too.

I did some work with a Kalman Filter, and my solution was to run all the processing in process() with a blank screen (with VSync disabled) which should be about as fast as you can get. Then the 3D render was done in physics_process() which runs at 60Hz by default (but this can be changed in the project settings).

You can use the --fixed-fps N command line argument to make the game simulate physics as fast as possible, while supplying a constant delta that is equal to 1.0/N. You can also disable the render loop temporarily in the Engine singleton (or using --disable-render-loop) to make sure rendering isn't a bottleneck (but the window will then appear to freeze while the render loop is disabled). See https://github.com/Calinou/godot-video-rendering-demo for an example of this.

10 months later