|
![](/i/fill.gif) |
> Alternatively, I make the "draw a background" a completely separate
> component that gets turned on or off depending on whether the code wants
> the background, or depending on the top-most screen of the screen stack.
> This is kind of what I'm leaning towards.
Yeh I played about a bit with variations on this idea.
Currently I'm using a "BlockDrawing" and an "AlwaysDraw" property of each
screen. If BlockDrawing is set to true, then all screens lower in the stack
will not have their draw methods called, *unless* they have AlwaysDraw set
to true. In this way I make a background image (could be animation in
future) with BlockDrawing and AlwaysDraw set to true, then build up my menu
screens above that with BlockDrawing true (so the main menu doesn't get
drawn when a sub menu is visible) and AlwaysDraw false.
The problem here is that even when the real game starts, the menu background
is drawn, wasting time.
I thought another method could be to arrange screens into "groups" of some
sort (maybe even each "screen" could actually contain a list of screens),
then you could put all the menu screens (including the background screen)
into a group/screen, and once the main game screen has faded in, the
BlockDraw property of main game screen group prevents the menu screen group
from being drawn.
I'm still working on it :-)
Post a reply to this message
|
![](/i/fill.gif) |