the implementation: it's easier to edit without triggering huge rebuilds
that way.
(Hmm. There's really no benefit, here, to using an anonymous namespace
instead of statics, but it seems better this way and I'm not sure why.
The normal admonitions against global variables don't apply here, since
static avoids namespace pollution and it's a singleton, but maybe it's
just habit asserting itself and anonymous namespaces circumvent that ...)
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.
Glenn Maynard