don't re-create things if we've only changed what's enabled. Use this
with the Lua interface, by making EnabledForPlayers a function returning
a table instead of a table.
fade them in and out at the same time; we do this by tweening the whole
row up and down, and fading each part of the row. This is a big pain,
because we're also tweening each part for other reasons, and these
tweens tend to collide. The whole thing is brittle and complicated,
and it's making fixing other problems a pain.
Try it a little differently: to fade the whole row, tween the alpha
along with the position of the whole row. Then, manually propagate
the changing alpha value to each part, using BaseAlpha, so it doesn't
affect other tweens.
This also helps segregate the fading: with the exception of the actual
propagation, OptionRow doesn't have to know anything about it. Before,
it had to constantly be careful that any tweening operations didn't
collide with the alpha tweening; often, one or the other would be cancelled,
resulting in either the change not happening at all, or snapping instead
of fading.
(This is still a hack, but it's more manageable; it puts control of high-level
tweening entirely in SOptionsMenu's control, instead of half in OptionRow.)
Foreground's update, caused by GAMESTATE->m_fMusicSeconds moving backwards.
This happens due to frame skips confusing GameSoundManager::GetFrameTimingAdjustment.
It expects that, when the framerate is stable, each frame will take 1/FPS.
If we skip a frame, it thinks one frame is 30ms late, and tries to
adjust by 30-16ms. Reduce the threshold for this adjustment to half a frame;
if we're that much late, the problem isn't scheduling jitter--we've probably
dropped a frame, and adjusting here is incorrect.
In case that isn't enough, clamp fDeltaTime in Foreground, too.
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).
to messages, and unify them with actor messages instead of having two major,
distinct, functionally similar messaging systems. This is an improvement over
a chunk of messages that are handled differently than all other messages, though.
options screens. (We don't ignore this at a higher level, because we
want to allow start when transitioning when it's not going to go to another
screen.)
Glenn Maynard