GameStateManager

Troubleshooting General Help
1

Hi all,

I am just going through some of the jme classes to see if I can get a better picture of everything. And I saw this line:



public void switchTo(String name) {
      rootNode.detachAllChildren();
      ..........
      rootNode.attachChild(current.getStateNode());
      ..........
}



Then i saw that a GameState contains a "render" method. So im just wondering, whats the point in the render method if you are going to attach whats going to be rendered to the root node anyway?

To be honest, i would rather not detach all children from the root node and just render the current state. Because there are some dummy objects that i would like to remain there even when switching states...

Or is there something i am missing?
2

indeedo :slight_smile:



So just getting rid of the rootNode.attach/detach would be enough. And reword the javadocs to highlight the new principal.



DP

3

Aha, gotcha. Yepp, maybe that’d be better… I mean, you could still have a skybox or something shared between the states, as long as it’s attached to the rootNode (as long as you draw the rootNode).

4
"DarkProphet" wrote:
To be honest, i would rather not detach all children from the root node and just render the current state. Because there are some dummy objects that i would like to remain there even when switching states...
Yeah, as spotted in this thread, detachAllChildren should be replaced with detatchChild(current.getStateNode())...
"DarkProphet" wrote:
Then i saw that a GameState contains a "render" method. So im just wondering, whats the point in the render method if you are going to attach whats going to be rendered to the root node anyway?

From this thread:
"Badmi" wrote:
You need a render method. There some cases in which you cant only use one root node such as drawing bounds or rendering to textures.
5

I have read both of those threads per :slight_smile:



But i still dont understand the need to attach/detach states, when they have a render method. That render method alone can copy with creating multiple nodes for rendering to texture/bounds…etc



I.e. in that state, have more than 1 node, and render each accordingly…



DP

6

Another thought on the gamestate stuff.



I think that the StandardGameState should have it’s render() method changed to this:



public void render(float tpf) {
      DisplaySystem.getDisplaySystem().getRenderer().draw( this.stateNode);
   }



thus allowing the removal of the redundant call:


display.getRenderer().draw(rootNode);


before


GameStateManager.getInstance().render(tpf);



See TestGameStateSystem.java line 93 (render() method).

Also, I'd like to propose that the gamestatemanager should be able to actually handle more than one state at a time. Instead of just switching between states, it should be able to switch between groups of states. I'll propose the exact code changes soon.
7

Hehe, each change brings it closer to the state management in Dirt. I guess I should have been less lazy and submitted that to begin with.

8

I’m in the same boat renanse… I ended writing my own state management back in May of last year. :stuck_out_tongue: We’ll get it standardized yet…

9

guurk, only drawing of the state node has been proposed and discussed a little bit here (at the end):

http://jmonkeyengine.com/jmeforum/viewtopic.php?t=1225



I think GameState groups could be useful as well.