Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualRavyne

Posted 28 November 2012 - 12:15 AM

Is the purpose of choosing a new state within the update to ensure that the 'old' state doesn't get deleted as soon as g_sceneObject is set to a new state?

If that's the primary cause of this, then you can solve the whole mess by making g_sceneObject a shared_ptr, and creating copy of the shared_ptr to it as the first step of update() -- this way if you overwrite g_sceneObject with the new state, the reference count on the copy of the old state will be decremented, and when you leave update it will decrement again and be deleted. The next time through you'll have the 'new' state.

From there you can move g_sceneObject into the state manager, and initialize it to a known-good state on construction, then you have no need for Scene_Null or NO_SCENE, because you can then assume that if m_sceneObject (or whatever you name it after moving it into the scene manager) is null you've reached the terminal state.

You'll need to provide a method to change SceneMgr's m_sceneObject member, and you can initialize the new state then and there (preferably by constructor rather than / in conjunction with initialize()), instead of in the update function -- in the SceneMgr::update function, m_sceneObject is either null (and your game has reached the terminal state), or valid and fully initialized.

Update becomes something like:

int SceneMgr::update() {
shared_ptr<Scene> scene = m_sceneObject;

return scene->update();
}

You probably won't need the SceneID enumeration at all, and scene manager won't need to know about all the different scenes that exist at all.

You'll have to give scenes a way to tell SceneMgr to change the scene -- you could pass each scene a reference to SceneManager (but that's kinda gross), you could pass a call-back function that changes it (which is better), or you could re-jigger things so that Scene::Update returns the next scene, or itself if its to stay in the same state -- shared_ptr should take care of all the reference count management automatically. A scene that kicks of any new scenes will have to know about those scenes and those scenes only, which is the way it should be.

#1Ravyne

Posted 27 November 2012 - 11:59 PM

Is the purpose of choosing a new state within the update to ensure that the 'old' state doesn't get deleted as soon as g_sceneObject is set to a new state?

If that's the primary cause of this, then you can solve the whole mess by making g_sceneObject a shared_ptr, and creating copy of the shared_ptr to it as the first step of update() -- this way if you overwrite g_sceneObject with the new state, the reference count on the copy of the old state will be decremented, and when you leave update it will decrement again and be deleted. The next time through you'll have the 'new' state.

From there you can move g_sceneObject into the state manager, and initialize it to a known-good state on construction, then you have no need for Scene_Null or NO_SCENE, because you can then assume that if m_sceneObject (or whatever you name it after moving it into the scene manager) is null you've reached the terminal state.

You'll need to provide a method to change SceneMgr's m_sceneObject member, and you can initialize the new state then and there, rather than in the update function -- in the SceneMgr::update function, m_sceneObject is either null (and your game has reached the terminal state), or valid and fully initialized.

Update becomes something like:

int SceneMgr::update() {
shared_ptr<Scene> scene = m_sceneObject;

return scene->update();
}

You'll have to give scenes a way to tell SceneMgr to change the scene -- you could pass each scene a reference to SceneManager (but that's kinda gross), you could pass a call-back function that changes it (which is better), or you could re-jigger things so that Scene::Update returns the next scene, or itself if its to stay in the same state -- shared_ptr should take care of all the reference count management automatically.

PARTNERS