[Solved] Loading a model -> Need of an AbstractGame instance?

Hi!



As a mean of learning, this is about making a Dungeon Master like game.

Basic, really.



The walls are stored in an xml file:

(...)
<Wall x="0.0" y="0.0" z="0.0" size="1.0" texture="basic_wall"/>
(...)



Digester & co.: ok

Other posts brought me to this snippet in order to have a texture applied to a shape:

TextureState ts = display().getRenderer().createTextureState();
Texture t = TextureManager.loadTexture(
            "img/textures/wall/basic_wall.gif",
            Texture.MM_LINEAR,
            Texture.FM_LINEAR
            );

ts.setTexture(t);
      
Node n = new Node();
n.setRenderState(ts);

wall.setData(new Vector3f(x, y, z), new Vector3f(l, h, w));
n.attachChild(wall);



The questions now.

1) an AbstractGame must be created in order to have a display object. This means my "terrain loader" must have an AbstractGame instance referenced, otherwise no display will be available. Coupling is bad.
What would you suggest to make display available: Adding a static getDisplay to the AbstractGame implementation?

2) "display" is protected. What design would you apply to access it from outside the package?
-> my version looks ugly, yet works:
public class BasicTerrainGame extends SimpleGame {

public static BasicTerrainGame app = new BasicTerrainGame();

public static DisplaySystem getDisplay() {
return app.display;
}
(...)
}

any suggestion for a less ugly / nice looking design?

3) Wiki reads it's better to set the TextureState as being the RenderState of a group of node whose shapes are applied the same texture.
Should then be designed a node tree based on the textures?
Also, Wiki reads nodes should group items by area.
-> One node holds all the similar walls in the level?
-> break the wall node in areas, each area having its node and it's RenderState set to a new instance of the TextureState?

I thank your patience...
  1. and 2): There is DisplaySystem.getDisplaySystem(), you can use that after the DisplaySystem has been initialized. It's static.
  2. I hope to be corrected if I am wrong, but I think sorting by RenderState is done by the engine now, so you can just build your Node hierarchy entirely based on spatial relationship for efficient culling.

Hi Hevee,



Your answers for 1 and 2 are working and it's not an ugly solution. Mine thanks upon thee!

:wink:



3 -> ok then! It's good for now :slight_smile:



thank you :slight_smile:

For #3, jME currently sorts by texture state if it is applied, otherwise it sorts by distance to camera.