- the editor sets "system_menu" to trick StepMania.cpp into not
allowing the operator menu button, to prevent losing data;
- the editor also sets "gameplay" in "playback" mode to influence
ScreenSyncOverlay and ScreenDebugOverlay; this breaks the above,
allowing scroll lock in play mode.
A similar problem happens when we push screens: scroll lock works
in the MiniMenus in the editor.
It's semantically unintuitive to call the editor a "system_menu", anyway.
Split out AllowOperatorMenuButton, and use it directly. Check all
screens, and don't allow it if any screen on the stack disallows it.
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 ...)
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.
Steve Checkoway