This commit is contained in:
Glenn Maynard
2002-09-03 10:09:22 +00:00
parent 40277568d0
commit edb4ee6e97
+33
View File
@@ -5,6 +5,39 @@ is better held on the list than in a CVS document. :)
Some of this is stuff I'm not quite sure how to deal with, but too
low-pri to bother bringing up on the list.
********
For the gameplay screen, we transition to the "Stage" display, sit
around for a long time, fade out the Stage display, then load the
gameplay screen and tween it in.
It'd be nice if we could go straight from one screen to another, tweening
one off and the other on simultaneously (with a delay so it doesn't
look like a jumble, but in parallel).
Here's the idea:
First, allow "buffering" a screen. This loads the screen in the
ScreenManager, but doesn't actually display it, so we have control
over when it starts tweening in. Screens will need to be adjusted
to only load actors in the ctor, and receive a startup message to
do the rest.
This alone will let us load the gameplay screen while the stage
screen is still displayed. Currently, we wait four seconds, fade
out, then spend another second or two loading; we should load then
sleep for the remainder, so we always get four seconds (and less
if we get rushed along by the start button).
Once that's done, we can go a step further: render the prepped screen
after it's loaded, set up crossfades (instead of two successive plain
fades) which look as good but don't take as much time; and tween in
parallel.
(Once *that's* done, we can figure out if we want to use this for
tweening menus, too. For example, old screen shows its keepalive,
preps the new menu, hides its keepalive, then both tween.)
********
We have different kinds of things we want to trace, and different
places to put them.