A state stack, reinitializable components, and related issues...

[josephbleau]

This morning I attempted to add the configuration window to the in-game escape menu. I went about this by making an important change to state handling. I introduced a "state stack." It's exactly what it sounds like, a stack that maintains a list of states. When you want to enter a new state you push it onto the stack. When you want to visit the previous state, you pop the stack.

Once this was in-place putting the configuration menu in-game was trivial, with one caveat: Changing the resolution does not automatically scale the UI elements, and because of how the components have been written it does not appear that it would be trivial to reinitialize them after they've already been loaded.

I think this is something that should eventually be addressed. And while I don't consider my implementation perfect, I do think that a state system capable of remembering and recalling previous states will be important to the versatility of the engine in the long run.

Maybe this can be something we eventually look into: making classes that would make sense to be reloaded on-the-fly capable of doing so.

Here is my branch with the state code: https://github.com/josephbleau/flare-engine/tree/state

Cheers

[hean01]

The current state machine as you figured removes previous state and replace with another, in this way we can save some resources instead of using a stack. Take this example stack:

cutscene -> title -> load game -> gameplay

This would keep memory resources for 3 gamestates while playing which is not optimal, however a stack based stateengine is nicer to work with.

Ofcourse we could have a mixed approach but that would make code complicated.. so imho the current state machine is preferred.

To solve the case you have changing options from in - game take a look at my cutscene implementation how to switch state and return to game play.