Screens typically have two general simple models of transitioning;
either the menu elements transition out, or we drop a fade on top
of everything. The former leaves the background in place, the
latter doesn't. Transitioning is usually used when we're going
to a screen with the same background; fading is used otherwise.
(There are combinations of these, and more complex modes, but
these are the basics.)
Traditionally, cancelling has always wiped. It usually goes back
to the title menu, which rarely has the same background; and it's
an uncommon path, so it's not worth setting up a full transition
for. However, for cases where we don't go all the way back, this
is incorrect; it looks very strange to press escape in the options
submenu or the player options menu, and to have it wipe the screen.
I've dealt with this in the past by setting up a "cancel" transition
that simply runs "Off" and waits. That works, but it's a pain, since
the wait duration needs to line up with the length of the transition.
Instead, add a transition mode "CancelTransitionsOut" that causes
Cancel to run the Out transition directly. (This also plays the
start sound, due to a discrepency right now: with Out, it's the
screen's job to play the sound, but with Cancel, it's the transition's
job. Figure that out later ...)
Ultimately, we should be able to have full CancelCommand transitions
if we want, but the SWME TweenOnScreen/TweenOffScreen code transition
needs to be completed first (replacing individual transitions with a
single "On"/"Off" command).
add TweenOnScreen. This only sends OnCommands, not XY, since it should be
the inverse of TweenOffScreen (and eventually, maybe screens can simply
play On/Off recursively).
members are loaded--they'll see resets, score finalization, etc. It
also results in smaller code, due to a g++ bug that causes constructors
to be emitted several times.
that gets called on first update. Note the difference between
using ThemeMetric<LuaExpression> and ThemeMetric<ActorCommands>:
with ActorCommands, you get the special, backwards-compatible
parsing; with LuaExpression, only a regular expression is parsed.
You can still only (cleanly) call one function, since "return"
is prepended: if you say "f() g()", it'll try to run "return f() g()".
I tried having a separate type for "expression" and "script", but
it seems confusing to have some metrics parsed as scripts and
some as expressions, allowing multiple functions in only specific
metrics. If you want to do that much, it's cleaner to create
a function and call it, anyway. If you just want to add diagnostics
quickly, you can say "Foo=(function() x() y() z() end)()". (I might
revisit this later.)
Glenn Maynard