ui xith3d

Engines, Libraries and Tools Xith3D Forums
#81

On a Swing interface, I guess it’s a trade off between development time, complexity of the UI and frame-rate. If you want to create a very complex UI in a short amout of time, Swing lets you do that, but it has a cost. Have you played Alistair_Dickie’s game? It uses the Swing UI extensivly.

Alistair_Dickie,

Do you want to take charge of the UI code? It’s all yours if you want it. Please contact me by email if you do, and I will get you set up. What we will do is move the package into the xith-tk as an optional package, not tied to the core (thus, no bloat).

Regarding excessive garbage collection, if you identify the wastage and submit a patch, I will commit it in.

Cheers,

Will.

PS. Here are two UI bugs which you can look at if you like. W

#82

Will,

These are both a little harder than they should be.

I am going to do some more work on my program and will do a little on the interface package but will not get to it for a few weeks.

I am currently looking at getting a really nice Text3D shape done. You should see that in the next few days.

Regards,

Alistair

#83

That’s great :slight_smile:

If you are interested, you can add Text3D as a package of the Xith3D toolkit, and it will be distributed with every copy of Xith3D downloaded.

Cheers,

Will.

#84

Hi, im new here and want to first tell you all that Xith3D is great and thanks for your fantastic work!

On this thread earlier…

What about making a bit unconventional renderloop like this:
`

BranchGroup mainScenGraph;
BranchGroup foregroundScenGraph;

public void run() {
while(true) {

        // render once with the main scene picking disabled 
        mainScenGraph.setPickable(false);
        foregroundScenGraph.setPickable(true);
        view.renderOnce();
        
        // do picking to see if the GUI is picked
        ...
        
        // render once with the main scene picking enabled
        mainScenGraph.setPickable(true);
        foregroundScenGraph.setPickable(false);
        view.renderOnce();
        
        // do your normal game logic checking
        ...
  }

}
`

This should speed things up since if the root of the scene is disabled from picking, the picking will pass over the scene without picking it. Now the picking speed will be determined only by the GUIs complexity and that cant be very huge…

Then after picking for the GUI the states are reversed and normal game logic take place, maybe including picking on the scene triggered by a mouse click etc…

#85

I’ve already written some code, where you can perform a pick on branchgroups directly without this setPickable stuff. (make a search in the forums) It would do the job, too. But I actually favor the way of rendering twice( first the scene and then the gui in PARALLEL_PERSPECTIVE) with jogl this should work and is probably much faster.

#86

That is not completely true http://www-128.ibm.com/developerworks/java/library/j-jtp11253/ explains how the generational garbage collector in the 1.4.x, 1.5.x and even 1.6.x work. There are two main parameters which will greatly improve the application performance and reduce the pause times:
-Xnm8m -XX:SurvivorRatio=6
this will create a young generation of 8 MB minimum size and 6 MB for eden and 2 times 1 MB for the survivor space.

With these parameters I was able to create a Java abased image viewer that did only pause for about 3 ms every few images (1280x768xRGB => 4 MB per image). Without theses parameters the allocation of the BufferedImage alone took 130ms according to Netbeans profiler.

And you have to be very careful with object pools because once you modify an old object (which was promoted to tenured generation) may keep the new object alive until the next major collection - this can cause very long pause times.

The same is true for objects that are larger then the survivor space. But this should not be the case in Xith3D - only textures are this large and are normaly long lived. Otherwise increate the young generation or reduce the SurvivorRatio (like 2 -> e.g. 4 MB eden, 2x 2MB survivor).

I hope this can help to demystify the Java GC a little bit :slight_smile: