-
Notifications
You must be signed in to change notification settings - Fork 2
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
Whole new state machine #12
Merged
Merged
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
this will hopefully let me have the run as a field on App and accessible from RunState and the future RenderState
copies the implementation of old `render_rows` with minor modifications. started work on an update function taking a RunUpdate from the RunState.
mostly copypasted code for window resizing/titling, added `StateChange::Reset` to `update()` and copy paste for that too
method only recreates the parts of `RenderState` that depend on the run, which is more efficient than calling `new()` when reloading a run. will still have to call `new()` when reloading config.
i'm not really sure how it behaved before, but now it will increase the number of splits on screen if there are more, starting at the top. if splits have been scrolled off the top of the screen, they will be re-shown before splits scrolled off the bottom. When shrinking the window, splits at the bottom are always removed.
this allows skipping splits to still have the expected color changes when you are ahead or behind later in the run, because previously- everything got really confused
persist the time value across pausing so that it's the same when you come out instead of recalculating for a frame, removing the weird blink of a different time
example of how nice it is to add new events now. just slap em in StateChangeRequest and add a relevant match arm and boooom.
it was already being used as such, and there was nothing actually checking it for whether or not to round, so it's been reappropriated.
this avoids having golds set on split, which caused issues when unsplitting if the unsplitted split was a gold.
mist 1.14.0 -> 1.15.0 mist-core 0.9.0 -> 0.10.0
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.
Reimplementation of the internal state machine will eventually allow for plugins and stuff to work. The principle that this is based off of is "sending events" between the input handler, the state of the run, which handles timing and timer state, and the render state, which handles actually displaying things to the screen. Theoretically, the renderer could even be implemented as a plugin at this point, but I wasn't going to go that far. Things that still need to be tested/fixed before this can merge:
Some other stuff I'd like to get through in this, since it's basically a complete rewrite