It’s just one thing I haven’t made up my mind about. When doing:
load state A
load state B
remove state A
load state A
The second time I’m loading state A, it goes much faster. Is this a bug or a feature? I mean, it’s clearly still allocated in memory, but if it’s needed later on, will it then be “overwritten”?
Maybe I could change the GameStateManager.removeGameState(String) from:
public void removeGameState(String name) {
GameState state = (GameState) states.get(name);
state.cleanup();
states.remove(name);
}
to:
public void removeGameState(String name, boolean keepInMemory) {
GameState state = (GameState) states.get(name);
state.cleanup();
states.remove(name);
if (!keepInMemory) System.gc();
}
But if it'll be overwritten later on, I'm prepared to call it a feature :)
I was hoping to integrate this into the GameSystem (infact, ive already done so). So that it, the entity system, entity, entityActions, entityEvents can go in at the same time.
Or do people not prefer that?
The beauty of a module system... it can go in on it's own and won't affect you negatively in any way.
Added a test, and a few other things (don’t know exact :)). Not much change, so instead of posting it here all over again, you can grab it from here
I called the package com.jme.game.state, but do whatever with it If you want to have it as a separate module, or merging it with the game system, or putting it into the core, it’s all fine by me
StandardGameState has render, switchTo and cleanUp as empty methods, but render and switchTo seem to be needed to run correctly. Is there a reason these methods are abstract and StandardGameState be made a abstract class?
Is there a reason StandardGameState does not have a setCamera method? Each state is creating its own camera, would there be times when we might want to share cameras between states?
There is this in the test:
// NOTE: When using the game state system you must ALWAYS do this.
SoundAPIController.getSoundSystem(properties.getRenderer());
Why is that?
4. I was thinking of putting the three state classes in com.jme.app, anyone see a problem with this?
@1: render, switchTo and cleanup doesn’t need to be more initialised than what they are in StandardGameState. Look at the test - the only thing that’s done in switchTo is changing the title. The reason StandardGameState is abstract is due to the need of derived classes to initialise the input handler. Should we instead initialise a default input handler?
@2: Good point - added that now.
@3: Forget about that :// It was only me forgetting to catch an exception in GameStateManager.switchTo. Fixed now.
@1: render, switchTo and cleanup doesn't need to be more initialised than what they are in StandardGameState. Look at the test - the only thing that's done in switchTo is changing the title. The reason StandardGameState is abstract is due to the need of derived classes to initialise the input handler. Should we instead initialise a default input handler?
Ah, understood. Made too many assumptions. :)
Everything looks good, I'll hold off for Cep or Renanse to give any suggestions or their blessing and I'll get it in place.
Dirt has a very similar system implemented. The main difference I see is that I had to split out certain initializations to allow for switching back and forth between the same few states. (For example, switching between the game and the menu screen and the resuming back into the game.) The split was between initializing GL things for the state and normal scenegraph items. I had to do this because of some issue with cameras and render to texture… can’t remember why now though! Maybe just the switchTo will handle this though.
Anyhow, if we ran into a similar issue later, we could always incorporate the changes into the classes so no big right now! I say green light.
If you want to have it as a separate module, or merging it with the game system, or putting it into the core, it’s all fine by me