network profile
| bio | website | |
|---|---|---|
| location | Austria | |
| age | 31 | |
| visits | member for | 1 year, 1 month |
| seen | Apr 29 at 22:06 | |
| stats | profile views | 0 |
|
Apr 15 |
awarded | Supporter |
|
Apr 13 |
comment |
Gamestate management without evil Singletons @DeadMG yeah, that might not be the most efficient solution... How would you rewrite this? Would you create stack allocated game state objects and store references to these inside the gameengine class? |
|
Apr 13 |
comment |
Gamestate management without evil Singletons @shad0w yes, vector::pop_back will destroy whatever object-type is stored inside the vector. The problem is, that you are storing POINTERS to CGameState objects (vector<CGameState*>). This means that ONLY the pointer will be destroyed when pop-ed, but not the object itself - you have to manually delete it. |
|
Apr 12 |
comment |
Gamestate management without evil Singletons The code on the linked site does not release the memory in the PopState or ChangeState methods. In theory you could rewrite the method to delete the pop-ed instance but then you get into more trouble: changing the game state normally happens while "executing" a game state i.e. inside the Update() method of the CMenuState you call game->PushState(new CGamePlayState()). So if you would like to pop the current state and automatically delete it you would delete the currently "executed" state. |
|
Apr 12 |
awarded | Teacher |
|
Apr 12 |
answered | Gamestate management without evil Singletons |
