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
Change: Refactor window ticks into game ticks and realtime events. #6780
Conversation
b86f719
to
93bae41
Compare
Friendly poke. Is this PR ready for review, or are you still working on it? |
Any status on this? |
93bae41
to
f044c30
Compare
…djust timers to work with milliseconds instead of ticks.
f044c30
to
4cbd88d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a shame that it can't have any effect at normal speed - the GUI movement speed is very noticeable after some time on fast forward! I imagine the "solution" to that would be to effectively run the GUI on fast forward all the time, which probably isn't all that viable...
This is something I wanted to tackle with my previous PR so that the UI elements would render/update each frame keeping the game logic at fixed update rate which this PR does I believe. |
@LordAro Can be changed, but I think that's a separate PR. Part of the issue of running the GUI always at full speed is you then end up delaying the game loop because of that. |
These changes uncouple GUI timing (used for e.g. animations, debouncing, refresh intervals) from game timing. This change is most visible when using fast-forward, although it is also noticeable on very slow savegames as well.
Timing intervals have been multiplied by 30 to convert from game ticks to milliseconds. Note that although MILLISECONDS_PER_TICK is 30, in reality I often see 30, 31 or 32ms per game tick, so some animations may differ very slightly.
These changes may need additional refactoring due to feature creep.