I am trying to implement JMEDesktop in my application to provide display elements on the screen (such as chat and event messages on the left side of the screen) and I'm getting some strange issues in ORTHO mode where the GUI will just disapear when I move the mouse around some. At the moment I don't really care about using mouse input with Swing, I want to keep my input the same and just display stuff up on the screen in front of the 3D. Here is the sample code I put together to demonstrate the problem:
/*
* Created on Dec 10, 2005
*/
package com.captiveimagination.rollarama;
JTextPane text = new JTextPane();
text.setSize(100, display.getHeight() - 25);
text.setText("TestingrnTesting AgainrnTesting even more text hopefully wrapping to the next line.");
//text.setOpaque(false);
text.setBackground(new Color(1.0f, 1.0f, 1.0f, 0.2f));
text.setEditable(false);
text.setForeground(Color.WHITE);
text.setLocation(0, 0);
pane.add(text);
pane.repaint();
pane.revalidate();
input.setEnabled(true);
}
protected void simpleUpdate() {
}
public static void main(String[] args) {
SwingGameTest sgt = new SwingGameTest();
sgt.setDialogBehaviour(BaseGame.ALWAYS_SHOW_PROPS_DIALOG);
sgt.start();
}
}
I know there were some bugs, but not sure if this was one of them or I was just doing something wrong. My bet is on the latter, but I just wanted to check. :)
Your rootNode is being culled (probably when the mouse is moving off the screen). Because you attached the GUI to the rootNode it gets culled with it. Because your GUI elements don't have any boundings they don't keep the rootNode from being culled. In most situations (read full game, you'll always have something on screen to keep it from being culled), but even still, it might be a good idea to either:
a) break your scene up into GUI elements (similar to how FPS Node is rendered) and the main scene. Keep them seperate.
b) set rootNode's cullMode to CULL_NEVER. Be careful with this though because child nodes will inherit this, so create a child that is CULL_DYNAMIC below. Basically, this is the same as (a) but organizing at the rootNode's child level.
This become less of a problem when you start building a true scene.
Doh! Hehe, I usually do a quick mock-up to make sure I know what I'm doing before adding the complication of the rest of the implementation, but it would seem the lack of complication was the source of my problem. :-p
My method (which is still being prototyped) is to create attach a node to rootNode called "Gui", to which I attach all widgets. This Gui node is set to never be culled and also has lighting disabled. Not sure if this is ideal but it seems to work in the very early stages.
Yeah, after I added it to Roll-A-Rama it seemed to still get culled every now and then so after telling the desktopNode to never cull it seems to work great. I might switch to doing something outside of the rootNode in the future, but for now this is easier.
Ok, well you attach it to rootnode, so rootnode will need the same flag set to prevent culling of the whole scene at that level.
You'll need to set other things you attach to rootNode (aside from hudNode) to CULL_DYNAMIC though if you want them to still cull when they are off screen.
Why not start your game and then after the first update is called add your gamestate to the game? That's what I'm doing in my game currently. I wrote GameManager that handles all the initialization and update and render calls for the GameStateManager and I added a method waitForStatus that doesn't return until a certain status has been reached in the game, namely STATUS_MAIN_LOOP. This is just an example of a way you can do it.
