Yeah, that’s similar to how I do it by now. Though I still have the scene switching logic in my Application class. I also switch the scene in BeginFrame as it was suggested earlier.
Took me some time to understand inheriting from Scene
is actually not that bad and kinda required for such a logic to work fine.
The only thing that still raises my eyebrows a little is that you call Scene?.Remove(), but the doc says it removes the scene from the parent node, but the scene is the root, so that shouldn’t have any effect, or should it?
Here’s my code, though it uses the UrhoSharp C# wrapper.
[code]public class Game : Application
{
private StageBase _currentStage;
private StageBase _nextStage;
public Game()
: base(new ApplicationOptions("Data"))
{
}
internal StageBase CurrentStage
{
get
{
return _currentStage;
}
set
{
// Do not immediately change the stage, and queue it to be done at the start of the next frame.
_nextStage = value;
}
}
protected override void Start()
{
Time.FrameStarted += Time_FrameStarted;
CurrentStage = new MenuStage(this);
}
private void Time_FrameStarted(FrameStartedEventArgs obj)
{
// Switch the stage if any was queued.
if (_nextStage != null)
{
// Give the stage a chance to cleanup (and possibly store its status later on). Then destroy all nodes.
if (_currentStage != null)
{
_currentStage.Stop();
_currentStage.UpdateEnabled = false;
_currentStage.Clear(true, true);
_currentStage.Remove();
UI.Clear();
}
// Activate the new stage and call its method to set itself up.
_currentStage = _nextStage;
_currentStage.Start();
_nextStage = null;
}
}
}[/code]
My extended Scenes are called “Stages” for whatever reason I might not like soon
[code]internal abstract class StageBase : Scene
{
internal StageBase(Game game)
{
Game = game;
}
protected Game Game { get; private set; }
internal abstract void Start();
internal abstract void Stop();
}[/code]