replit
Fixed deltaTime
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.
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
https://github.com/replit/kaboom/assets/55938439/bd10e7dc-b480-441c-9355-bc41826f3c07
https://github.com/replit/kaboom/assets/55938439/a0638067-429e-44fa-b9e1-7cd009c030d3
Physics and game updates/rendering are usually decoupled. Sometimes even in separate threads. Physics takes fixed steps, like one sixtieth of a second in Box2D. While updates and rendering just take the delta time between frames.
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.
Physics and game updates/rendering are usually decoupled. Sometimes even in separate threads. Physics takes fixed steps, like one sixtieth of a second in Box2D. While updates and rendering just take the delta time between frames.
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)?
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
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