Refactor screen save&restore logic #646
Merged
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.
This PR is only refactoring; it should not cause any visible changes.
A common pattern in the Brogue codebase is to do the following:
The second argument to
overlayDisplayBuffer
is used to store the old screen, so that drawn graphics can be reverted later. This is convenient, but it makesdbuf
andrbuf
usage look very similar, since they're both justscreenDisplayBuffer
s.We can make the distinction clearer by introducing new functions:
The common pattern at the top can now be spelled as:
in particular, with a few exceptions,
saveDisplayBuffer()
is now always called in the same function that callsrestoreDisplayBuffer
, on the same variable. This makes it relatively easy to ensure that the screen is always getting restored when we mean it to, and less code-tracing across multiple functions is needed.From this change, the number of calls of
overlayDisplayBuffer
drops from 60 to 23. So we see that actually many of its calls were solely for saving/restoring the state of the screen, mixed in with calls that actually draw new graphics to the screen.