-
-
Notifications
You must be signed in to change notification settings - Fork 20.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Getting negative delta
values for _process
#26887
Comments
Reproducable on Ubuntu 18.04.2 LTS (Kernal x86_64 Linux 4.18.0-17-generic) Godot: v3.1.stable.mono.official The issue only seems to come during very high stress (In my example, a ton of high poly spheres are spawned) |
To anyone that can reproduce the original issue The patch just tries to avoid some unnecessary math, limiting potential overflows and hopefully minimizing numerical errors: (there is also a 3.1 version of this patch: https://github.com/Faless/godot/tree/spike/clock_info_3.1 ) |
I can still reproduce this in all branches. More data below Ubuntu 18.04.2 LTS @Faless branch Standard: Bug is Reproducible Seems to happen somewhat randomly, and behavior can be changed based on background processes and performance Updated test project: |
Can you also provide CPU and motherboard details?
…On Thu, Oct 17, 2019, 01:04 Nathan Franke ***@***.***> wrote:
Ubuntu 18.04.2 LTS
Kernal x86_64 Linux 4.18.0-17-generic
GeForce GTX 960
@Faless <https://github.com/Faless> branch
<https://github.com/Faless/godot/tree/spike/clock_info> Standard: *Bug is
Reproducible*
Master Standard, Master Mono: *Bug is Reproducible*
*Updated test project*:
*This project uses GDScript rather than C# so that the bug is testable in
the Standard version.*
GodotTestProject.zip
<https://github.com/godotengine/godot/files/3736690/GodotTestProject.zip>
*If anyone else is able/unable to reproduce this, please reply*
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26887?email_source=notifications&email_token=AAM4C3WABZN6BSCIN5TZFN3QO6MWPA5CNFSM4G46HJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOGLOI#issuecomment-542926265>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4C3TVHDGNB2ACEDNCCPDQO6MWPANCNFSM4G46HJOQ>
.
|
Also, does this also happen when vsync is enabled? (I see it's disabled in
project settings). How many fps are you getting without vsync?
On Fri, Oct 18, 2019, 13:50 Fabio Alessandrelli <
fabio.alessandrelli@gmail.com> wrote:
… Can you also provide CPU and motherboard details?
On Thu, Oct 17, 2019, 01:04 Nathan Franke ***@***.***>
wrote:
> Ubuntu 18.04.2 LTS
> Kernal x86_64 Linux 4.18.0-17-generic
> GeForce GTX 960
>
> @Faless <https://github.com/Faless> branch
> <https://github.com/Faless/godot/tree/spike/clock_info> Standard: *Bug
> is Reproducible*
> Master Standard, Master Mono: *Bug is Reproducible*
>
> *Updated test project*:
> *This project uses GDScript rather than C# so that the bug is testable in
> the Standard version.*
> GodotTestProject.zip
> <https://github.com/godotengine/godot/files/3736690/GodotTestProject.zip>
>
> *If anyone else is able/unable to reproduce this, please reply*
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#26887?email_source=notifications&email_token=AAM4C3WABZN6BSCIN5TZFN3QO6MWPA5CNFSM4G46HJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBOGLOI#issuecomment-542926265>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAM4C3TVHDGNB2ACEDNCCPDQO6MWPANCNFSM4G46HJOQ>
> .
>
|
Motherboard: Gigabyte H170-Gaming 3 Not at home to check Vsync enabled, but I always get 60fps using it |
Yeah, sorry.
I meant how many fps you get _without_ vsync.
And separately, if the negative delta problem is present _with_ vsync.
Sorry for not being clear :-)
…On Fri, Oct 18, 2019, 15:54 Nathan Franke ***@***.***> wrote:
Motherboard: Gigabyte H170-Gaming 3
CPU: Intel i5 6600k
Not at home to check Vsync enabled, but I always get 60fps using it
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26887?email_source=notifications&email_token=AAM4C3R644ODLOQOUD5PZ63QPG5X5A5CNFSM4G46HJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBURK7Y#issuecomment-543757695>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4C3TSSXQQEFH76VVU47DQPG5X5ANCNFSM4G46HJOQ>
.
|
No problem edited my response already |
Sorry to insist, but does the bug happen when vsync is enabled? That is
quite crucial to know. Thanks!
…On Fri, Oct 18, 2019, 17:15 Nathan Franke ***@***.***> wrote:
No problem edited my response already
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#26887?email_source=notifications&email_token=AAM4C3VOXIPGRLZW7UCZS6DQPHHKTA5CNFSM4G46HJO2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBUZWZQ#issuecomment-543791974>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAM4C3RI7UXRORZRYCL4K5TQPHHKTANCNFSM4G46HJOQ>
.
|
I cannot reproduce this bug with VSync enabled |
I see, and am I guessing right that when you get negative deltas it's actually an incredibly small negative value? (i.e. negative zero |
Correct. The values are quite small. Here is a log
Therefore it is likely unrelated to the Android bug that was fixed (mentioned above) |
I found a very easy way to reproduce this. I am assuming it only happens on Unix since the problem is likely in Here is the script that has <0 delta consistently after 1-2 seconds
|
@zmanuel well in my case I didnt really have much of a choice, it's in calculation of a derivative. |
@Zylann That is an interesting point. If you get back a 0 in delta, it is does represent there is/was no time in which to do anything, and anything multiplied by delta 0 is going to do nothing. So why call the function? I am wondering if there are some cases with 0 delta where you'd still want to execute something not dependent on time, but wouldn't want to locate it in the physics process loop. If the goal is to not surprise people (oh no, game was running fine for weeks, but today crashed because of divide by 0?!) or add extra work to the developer (maintaining code for guarding against 0 in dozens to hundreds of places), it probably shouldn't execute delta <= 0.0, and just be documented it might not execute at all if it's out of time. |
@avencherus A legitimate case where you would want _process to still be called on zero timesteps is if you want to implement your own framerate statistics, you'd miss render frames. A slightly more contrived example would be old-school fixed timesteps; some game may decide it works best if it engages v-sync and just assumes to get _process-calls 60 times per second. Sure, that means it gets slowdown if frames are missed or the framerate drops to 30 fps, but in some cases that may be preferable to the alternative. I remember reading in a very old shmup review something along the lines of "The game slows down when the action gets too much, but then again, that helps to get through the tougher spots." Ultimately, what I guess I'm saying is that control over the number of physics steps and delta arguments should be given to the game, with reasonable defaults. @Zylann Negative timesteps are out of the question. Even if you implement your timestep physically accurately, negative steps just reverse the mechanical time, not thermodynamic time. Take your basic fake friction update: Regarding your derivative, you may already be getting problems at small timesteps. I assume you're doing something along the lines
Since old_value and value are likely to be very close, that runs into the old numeric problem of cancellation and elimination of significant digits. The lowest allowed delta argument in the old version of the PR was 1E-6; (single precision) floats are only accurate to about 1E-8, which only leaves your derivative with an accuracy of about 1/100, provided it is of the same size as value, approximately. If it's smaller (say, an object moving at 1 m/s, 100 m away), you're completely out of accuracy. |
delta
values for _process
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below zero. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes godotengine#26887
I was just wondering where I got some NaNs showing up in a Label, and after looking into it, I noticed it happens when some of my game logic inside _Process is called with exactly 0 delta. Funnily enough negative delta seems to work fine with the calculations I'm doing. Based on that I found this issue. Just want to let you know that I'd much prefer if Godot would only pass delta > 0 to my code, so that I don't have to look through all of my _Process methods looking for places where I need to bail if delta is <= 0. Even if that would be an option that needs to be explicitly enabled. |
I am getting a delta of -0,005539333 on Win10 using So I don't think it's specific to Unix. As |
I hit this same problem in Godot 3.2.4rc3 (on Xubuntu 20.10 x86_64). There was some discussion on whether zero is a valid value for delta at all. If I'm not mistaken, one more case where zero delta is expected is when using small (or zero) value in Engine.time_scale. My code currently handles zero deltas but I wasn't prepared for negative values. |
A fix has been ready for merging for quite some time now, any ideas how we can actually get it merged? |
@zmanuel We can't merge it in |
I understand. Who can I bother and when would be the right time to go nagging? A week or so after 3.2.4 is out? |
akien-mga is the one who merges pull requests, and I think you can ask him once 1-2 weeks have passed after 3.3's release. |
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below 1/8th of the input step. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes godotengine#26887 Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below 1/8th of the input step. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes #26887 Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro>
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below 1/8th of the input step. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes godotengine#26887 Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro> Cherry-Pick from 6be702b.
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below 1/8th of the input step. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes godotengine#26887 Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro> Cherry-Pick from 6be702b.
Three attack points, all after the regular calculations: 1. Prevent negative physics timestep counts. They could occur if physics_jtter_fix is changed at runtime. 2. idle_step is not allowed to go below 1/8th of the input step. That could happen on physics_jitter_fix changes or heavily fluctuating performance. 3. Prevent that the idle_step modification breaks the promise that Engine.get_physics_interpolation_fraction() is between 0 and 1 by doing more physics steps than the base system wants. Fixes godotengine#26887 Co-authored-by: Hugo Locurcio <hugo.locurcio@hugo.pro> Cherry-Pick from 6be702b.
Godot version:
Godot 3.1. RC 1
OS/device including version:
Windows 10 Home 64-bit, Geforce GTX 860m
Issue description:
I already found some similar issue, but it was related to android only. Therefore I named the issue similar but the error also seems to occur on windows machines.
I noticed my script crashes because of a division by zero (Stripped down to relevant part):
For my case, angle = 0. If delta is negative the first code path is executed and results in a division by zero error. This happens sometimes when I start my game and do not move my character.
If this is relevant: I use the bullet physics with KinematicBody and StaticBodyies.
Minimal reproduction project:
I would provide the project if not easy to reproduce, I think a simple print if delta < 0 is sufficient.
The text was updated successfully, but these errors were encountered: