Don't speed up fastloop() under accelerated time
#939
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Daxtorim
force-pushed
the
no-loop-speedup
branch
from
f52ccdf
to
e2b1626
Compare
Daxtorim
force-pushed
the
no-loop-speedup
branch
2 times, most recently
from
3cb6655
to
aa57f8f
Compare
The `global.settings.at` variable was turned into units of milliseconds and the hardcoded factor of 2.5 all over the place was removed. `global.settings.gameSpeed` and `global.settings.atMultiplier` were introduced and the timers for the game loops were added to `webWorker` to calculate the correct factor where needed. `atrack` variable was removed since it was equivalent to `global.settings.at` and therefore redundant. Gamespeed was added to topbar and removed from tooltips. The `atMultiplier-1` is necessary in the topbar display as well as in `longLoop()` in `src/main.js` because while the game runs at n-times speed, only (n-1)-times are actually the bonus speed and the remaining 1-times is the normal game which should not count against the bonus time.
Instead of simply running the game in tighter loops, multiply resource calculations by game speed. This is only done for `fastloop()` for now as most other code is tightly build and balanced around the timings of `midloop()` and `longloop()`. In a few places a `++` was replaced by `4*time_multiplier` to account for the loop running 4 times per second and `time_multiplier` being 0.25 under normal game speed.
The previous versions all assumed `midloop()` would run exactly once a second. This is not the case under accelerated time. This will correctly subtract the time between `midloop()` calls from timers such that the displayed timer accurately represents real time left. Currently this is done for the spy's training and mission timers as well as the gene mutation timer.
Daxtorim
force-pushed
the
no-loop-speedup
branch
from
aa57f8f
to
a2d1efa
Compare
Daxtorim
force-pushed
the
no-loop-speedup
branch
from
a2d1efa
to
187ebfa
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Instead of running a fairly resource intensive loop even more often than normal, this will multiply all resource calculations by game speed. There already was a
time_multipliervariable everywhere, it just wasn't really used in a way it could have been. Instead of maxing a core on my old laptop under accelerated time, now it only sits at ~60% of a core 😅.It also has the nice side effect that the displayed resource production values are now accurate under accelerated time. As a result of that the time estimates in the build queue are showing real time as well instead of ticking down at double speed.
The
midloop()andlongloop()timers weren't changed, as most code is tightly build and balanced around those timings and introducingtime_mulitpliervariables in those functions would be a massive undertaking.