Scripts can already use GetTopScreen to get this. However, that function
also returns data that may not be what's wanted. For example, commands
can be run on screens that aren't on top (eg. via broadcasts). So, using
GetTopScreen as a fallback for LoadingScreen may cause latent bugs;
screens should behave properly even when they're not on top, even if
they're using queued broadcasts to kick off animations, etc.
in Screen, by calling SetFOV to make ActorFrame do LoadMenuPerspective.
That broke screen backgrounds, which are rendered outside of any
screen, so they always used 640x480 (the default).
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 ...)
Glenn Maynard