-
Notifications
You must be signed in to change notification settings - Fork 227
Fixed deltaTime #757
Comments
cc @slmjkdbtl |
Tried to fix this for about 2 hours now. Used a variety of replacing built-in functions that used deltaTime with ones that didn't, and editing Kaboom's code itself. The only method I've found to work so far is in app.ts, setting dt() and realDt to both 0.003. Although extremely slow, it calculates precisely. Anything much higher (the speed it should actually run), it gets way inconsistent. I've provided 2 videos with 0.003 & 0.01. 2,000 cycles to who can fix it 2023-08-08.18-44-22.mp42023-08-08.18-42-22.mp4 |
I'm interested in this too, will investigate this week |
Physics and game updates/rendering are usually decoupled. Sometimes even in separate threads. https://box2d.org/documentation/md__d_1__git_hub_box2d_docs_hello.html#autotoc_md24 You can accumulate delta time in your loop, and calculate how many physics steps at constant time-step you need to call. Then just call update and draw as usual. |
I tried to rewrite it in Planck for about 2 hours & I didn't get far at all. I've proven it's possible with Kaboom, but just needs tweaking from someone more experienced in the internals to work. I really don't want to rewrite the whole thing because of a fixable frame rate issue. What is needed is for no frames to be dropped, with each frame having a strict deltaTime, so that way if I set it to be 30FPS it will be simulated like it was a perfect 30FPS even if it's not. |
Nearly got it working with a deltaTime tweak, but it switches between 5 end positions constantly. |
Hi! I've came for the bounty, but I may not be experienced to help in this case... Anyway, are you trying to cap the frame-rate or to make the frames independent (or both)? |
To edit the Kaboom.js code to have each frame have a fixed deltaTime without any dropped frames, ever |
I have came for the bounty I have 5 years of experience of Kaboom.js because i had to do this with someone else project |
Kaboom.js hasn't been around for 5 years. Lol. |
Yes it has for other softwares it has because I have made it for a game before |
Completely given up on it at this point, going to move to p5play. |
In my project, I'm dealing with a physics and logic-intensive simulation where the layout is always the same when it starts. However, the hardware's unpredictability causes the simulation to end at different frame counts, leading to varying outcomes each time.
To fix this issue, fixed deltaTime is needed. The idea is to make each frame independent of the time that has passed, using a fixed time window, like 33ms. This way, regardless of whether 30 frames take 2 seconds or 0.1 seconds, they will yield the same result. I want to ensure that frames are not rendered continuously but instead wait if calculated early to maintain a fixed FPS. This approach will allow each frame to be consistent and enable the simulation to catch up on any missed calculations, ultimately preserving precision in the results.
How can I accomplish this? I understand it may be difficult, so 1000 cycles to whoever comes up with a solution or PR.
The text was updated successfully, but these errors were encountered: