This pushing screens without them needing to be aware of it. (This will also allow
a pushed screen to replace itself with another pushed screen without having to
propagate the finalization message across; that'll make more sense if the rest of
this pans out ...)
attempt to explain what broke.
Ben, every remark and commit from you is rude and derisive, and this
project doesn't need that. You've expended my patience. If you refuse
to be civil, leave.
Prepare backgrounds, too.
Disallow calling SetNewScreen from a screen ctor/Init; it complicates things.
When loading a new screen (through LoadDelayedScreen), load the
screen with PrepareScreen, to reduce code paths.
re-set in the new screen's ctor." Don't do that--don't assume that the old
LoseFocus will be called before the ctor or Init. If you're doing something that
interacts with state changed by focus, do it in the first update, when you're
guaranteed to have focus. Make no guarantees about who has focus when
a new screen is constructed; only that LoseFocus will be sent before GainFocus,
and GainFocus before the first update.
GAMESTATE by then, so much of it is uninitialized, and we should not load
screens until that's done. (fixes valgrind warning due to IsEventMode()
being called from SSystemLayer)
path would return immediately in SetNewScreen, loading in the next update,
and the "undelayed" path would load under SetNewScreen. Instead, always
load on the next update, and just change the behavior (with "delayed" deleting
the old screen first). These two code paths are both criticial, and they were
too different, leading to inconsistent behavior; this way is simpler.
move sync display/saving out of complicated ScreenGameplay
show sync UI in editor playback as well as gameplay
revert sync from in-memory backup, not from disk
move more functions into debug overlay
Glenn Maynard