[x] If that doesn't prevent the initial "big bang" then investigate the actual bug that is causing it (probably due to the delay between the construction of the Time counters and their first update)...
[x] In that case a wait time in run() (see below) should actually worsen the situation! UPDATE: IT DID! :)
-> Since backend.clock auto-starts on its construction(!) (a kinda useful artifact of SFML's Clock), after which lots of other chores still remain before the first update cycle (where the next timestamp is taken), that huge initial interval has caused a massive spike, causing the explosion...
[x] Just restarting the timer right before starting the update loop solved it.
-> #503
OK, so these weren't necessary then:
[ ] It must be done inside run(), unfortunately, because it must have the all setup ready (especially all the IO and gfx).
[ ] Add add --no-warmup-delay to disable.
But then, the initial explosion is still a cool feature, so:
Timecounters and their first update)...run()(see below) should actually worsen the situation! UPDATE: IT DID! :) -> Sincebackend.clockauto-starts on its construction(!) (a kinda useful artifact of SFML's Clock), after which lots of other chores still remain before the first update cycle (where the next timestamp is taken), that huge initial interval has caused a massive spike, causing the explosion...-> #503
OK, so these weren't necessary then:
run(), unfortunately, because it must have the all setup ready (especially all the IO and gfx).--no-warmup-delayto disable.But then, the initial explosion is still a cool feature, so:
-> #504 to trigger a Big Bang explicitly...