delta in _process is incorrect when force_fps is low

[tinyleolin]

Godot version:

Godot Engine v3.0.6.stable.official.8314054 (installed from Steam)

OS/device including version:

Windows 10 version 1803 (OS internal version 17134.471)

Issue description:

When setting force_fps to 2, the delta in _process(delta) is far smaller (which is 0.133333) than the actual time period between two frames (which is 0.5).

Steps to reproduce:
Just set the force_fps to 2, and print(delta) in _process.

[tinyleolin]

#5332 Setting force_fps to 2 also makes the editor very laggy after reopening the project.

[timoschwarzer]

I'm not sure if _process is even guaranteed to only run once per frame. I think it's guaranteed to run at least once per frame.

[tinyleolin]

@timoschwarzer In my test case, _process is called only once per frame, but delta does not equal to the period between two frames.
Just enable print_fps and you can see the print(delta) output and "Game FPS: 2" showing up in pair.

[timoschwarzer]

@tinyleolin Thanks for clarification. I can reproduce this issue in 3.1-alpha4. @akien-mga

Reproduction

Set force_fps to 2.

func _process(delta):
	print(str(OS.get_ticks_usec() / 1000000.0) + " - " + str(delta))

Output:

Note that if force_fps is set to other values that should result in delta being higher than 0.13333, delta is still ≈0.13333.
delta is never higher than approx. 0.13333.

[akien-mga]

This is likely just that the delta is not updated when this logic is used:

godot/main/main.cpp

Lines 1934 to 1942 in 9cb1823

	int target_fps = Engine::get_singleton()->get_target_fps();
	if (target_fps > 0) {
	uint64_t time_step = 1000000L / target_fps;
	target_ticks += time_step;
	uint64_t current_ticks = OS::get_singleton()->get_ticks_usec();
	if (current_ticks < target_ticks) OS::get_singleton()->delay_usec(target_ticks - current_ticks);
	current_ticks = OS::get_singleton()->get_ticks_usec();
	target_ticks = MIN(MAX(target_ticks, current_ticks - time_step), current_ticks + time_step);
	}

Set fixed_fps to 2.

I guess you mean "debug/settings/fps/force_fps"? fixed_fps is a command line option and sets the physics step (_physics_process), so it would be expected that the idle step (_process) differs and continues running at ~60 FPS / as fast as it can if vsync is off.

[tinyleolin]

@akien-mga Yes, "debug/settings/fps/force_fps" is exactly what I mean.

[timoschwarzer]

@akien-mga Whoops, that was a typo. 😅

[Toshiwoz]

I am experiencing this too, i my case it's affecting tween duration, if I force FPS to any value below my computer's limit it affects it (I think, but it's not proven) proportionally to the difference between the actual machine FPS limit and the forced one.
In other words, if force FPS is a very high value, say 900 FPS, it should not affect, but if I set 60 it does change the tween time noticeably (for example instead of lasting 2 secs it lasts 0.2).

In my case this feature is needed because when I do screen recording, without an FPS limit, Godot does not leave enough CUP to OBS or S>G.

So, the related fix #24748 does not seems to fix the problem (unless it's not part of 3.2 beta4).

[TheDeafCreeper]

I would just like to add that this seems to occur even with just a low fps even if not set (in my case less then 1).

[aaronfranke]

0.13333 time elapsed per frame would mean 7.5 FPS. This issue may have something to do with the limitation of Godot where physics tickrate is capped at 8 times the game's framerate, since 60 / 8 = 7.5. What happens if you change the physics tickrate (Project settings -> Physics -> Common -> Physics FPS)?

[ludomosa]

This is still an issue.

Set the physics FPS to 240, then force FPS to any value below 30; watch as _process delta never dips below 0.0333 (stuck at 1/30th of a second, or 8x that of physics delta.)

If this is intentional, then a warning should be produced so the user knows that delta is incorrect, and this 8x relationship should be documented. Otherwise things just seem to slow down with no clear reasoning as to why.

[Zireael07]

@ludomosa: I believe the 8x part has recently been documented.

[Calinou]

Closing in favor of godotengine/godot-proposals#1893, as feature proposals are now tracked on the Godot proposals repository.

The current behavior is done by design to prevent the engine from freezing due to heavy physics calculations at low FPS. It's now documented as of #55667.