top screen. This allows a screen to push a helper screen, which can then
enter an entirely separate set of helper screens before one pops back.
(For example, a screen could push ScreenServiceOptions to enter the options
menu, which then replaces itself with the various options menus, and finally
pops back to the original screen when the player backs out entirely.) (Some
support is still missing to allow non-special-case use of this; coming soon ...)
However, in rare cases we want to kill all screens on the stack, regardless
of how many there are (operator menu). Fix that case.
- preparing and reusing screens used in a loop (eg. attract), a conceptual stack
(eg. options menu), or a real stack (ScreenPrompt)
- automatic cleanup once you load a screen that isn't preloaded; this gracefully
handles unusual or forgotten exit paths (eg. pressing the system menu button)
- reusing some screens in a group and loading others on demand
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.
Glenn Maynard