Sharing some innovation, CPU cycle reduction.

newmodels

Maybe this idea has already been known, but I wanted to share it.

In oblivion a video game from long ago, a editor called TES construction set was released for it. It allowed editing the game scripts of the game Oblivion.

I noticed that the quest scripts where donig lots of cpu cycles, lots of them. I then came up with a way to reduce those cycles increasing my FPS all the way into 60.

Godot allows similar way of reducing cpu cycles. In godot it's called delta. taking delta, if it's not time yet, then don't do anything.

For example: The TES construction set had scripts that checked the players position, about 3 or more position checks per script. that's lots of cpu cycles when you count how many times it's called per second. I was able to reduce those cpu cycles by not checking the position for the quests until it was time to check. So, about 0.1 seconds or more. Plenty of accuracy on the timing to catch the players position.

Other scripts in the TES construction set would check to see if the player had started a quest, or if the player had been in the INN room and if it was time to clean the INN room. By putting this timing reduction in the TES construction set I was able to get more than 60FPS. That was on an old Pentium D running at 2.8ghz.

I believe I was able to elimate millions of cpu cycles.

func _proc(delta): timecheck+=delta if(timecheck<0.1): return timecheck=0

...cpu cycles to reduce...

pass

cybereality

Well I'm not sure the cycles matter as much as what you are doing in the main loop. CPUs are super fast these days and can handle a lot. However, if you have unnecessarily complex code happening every frame, then this can slow things down. The best way is to make a game event-driven using Signals, that way you are not constantly checking for rare or unlikely events.

fire7side

Where this really matters is when you are doing distance checks for ai. Instead of checking distance every frame, you can check it every .25 seconds and not notice it in the way the game plays at all but will cut down the cpu work a lot. Good place to use a timer, also. This guy in Unity did that and he went from only being able to deal with a few characters to as many as he wanted. You can also get relative distance by using the distances squared because the math is so much simpler and generally you are looking for the closest guy.

cybereality

Yes, that is what I was talking about with complex calculations.

Kojack

The QuakeC language (in the game Quake) had a concept of think and nextthink inside of entities. Think was a function pointer, you'd assign a logic function to it. Nextthink was a floating point time (seconds) from level start. When the current time passes an entity's nextthink, the think function would be called. The think function then could set a new nextthink to make the process repeat.

You could therefore use it as a state system. Each think function could set which function happens next and how long before that happens.

https://www.moddb.com/games/quake/tutorials/quake-c-think-and-nextthink

cybereality

There are other ways to do it too. For example, you can break calculations between frames. Like say you have to check the position or distance from the player to 60 enemies. Instead of checking them all every frame (which would be too slow), you could check only 1 or a few each frame. If you used a timer, and checked every second all 60 enemies, this could lead to frame spikes or stutter. Instead, every frame you check 1 enemy out of the list. Then next frame you check the next enemy. After 60 frames (or 1 second) you have checked all 60 enemies and can loop back to the start of the list. But this is much better as it is consistent, all your frames will take around the same time. Rather than having it be super fast for 1 second and then slowing down for 1 frame, which causes stutter.

fire7side

I've done that, but I can't remember what it was for. But, if you do 1/4 second, let's say you have many independent ai enemies checking distance and making decisions, it will naturally break up the load, especially if it starts at a certain trigger of some kind. You only have to make sure they don't all perform the distance checks on the same loop. Start at a random time or something, but chances are it will naturally break up the load. Just spawning the enemies will probably put them on a different time loop. I don't do that type of game so hardly ever run into a problem. We just tend to think something needs to be done every frame and there are all kinds of things where a 1/4 second test is fine. It generally only matters when you start cloning them. I'm pretty sure I do things like you said on arrays. Instead of cycling through them, just operate on one item of an array at a pass through and keep track of position if there is a lot of work to do on each item.