JOGL Support (JOGL2 that is)

Development
81
@normen said:
Edit: Btw, I successfully compiled gluegen and the core of jogl in an XCode project using the macosx headers mostly, idk if it works though ^^

It's a great piece of news.

@normen said:
No NEWT? So that means no "simple, native" display yet? Only Canvas then? Just to know what to test.

It is still based on AWT just to perform some tests before switching to NEWT.
82

Hi



Iā€™m still working on the shader-based renderer as you can see on the repository.

1 Like
83

I just have to fix some small things in the render calls and the shader-based renderer should be ready for the tests too.

1 Like
84

Cool. I am having issues with my jme/java setup atm so I canā€™t really test anything normally. I added jogl to the build though and the jars are created in the ā€œoptā€ folder while being referenced in the manifest of the main jME jar. So you only have to copy in the jogl jars and then add the correct native to the classpath when running.



Say, the natives extraction system looks like you always have to have only the ā€œrightā€ binary jar on the classpath. Our system can have all in subfolders and will extract the correct one for the platform that its being run on. Would this work with your extraction system too? Else its no problem, we can use ours then.

85

Okay, playing around with this now and it freezes when I change ā€œTestBrickWallā€ to use the JOGL renderer like this:

[java] public static void main(String args[]) {

TestBrickWall f = new TestBrickWall();

AppSettings settings = new AppSettings(true);

settings.setRenderer(ā€œJOGLā€);

settings.setAudioRenderer(ā€œJOALā€);

f.setSettings(settings);

f.start();

}

[/java]



I was daring and used Java7u7 on OSX 10.8.2 :slight_smile: Is this supposed to work or is this not r11 (or what was it that fixed those latest issues)? Iā€™ll try with Apples Java1.6.



More info: I see some grey-ish square for like one or two frames in the upper left corner of my screen which then seems to move to the panel. Then I get the SPOD.

86

Actually, the ā€œrightā€ binary has to be in the same directory than its Java ā€œfriendā€ but not in the classpath. If your system extracts the binary in a different folder, you will have to modify the library path at runtime which is perfectly doable.



The shader-based renderer should be ready now even though the whole renderers are still based on AWT.

87
@gouessej said:
Actually, the "right" binary has to be in the same directory than its Java "friend" but not in the classpath. If your system extracts the binary in a different folder, you will have to modify the library path at runtime which is perfectly doable.

The shader-based renderer should be ready now even though the whole renderers are still based on AWT.

I have extracted the binary manually to the project root and it seems to be able to load them without any jar antics. Also check out my update in the last post.
88
@normen said:
Okay, playing around with this now and it freezes when I change "TestBrickWall" to use the JOGL renderer like this:
[java] public static void main(String args[]) {
TestBrickWall f = new TestBrickWall();
AppSettings settings = new AppSettings(true);
settings.setRenderer("JOGL");
settings.setAudioRenderer("JOAL");
f.setSettings(settings);
f.start();
}
[/java]

I was daring and used Java7u7 on OSX 10.8.2 :) Is this supposed to work or is this not r11 (or what was it that fixed those latest issues)? I'll try with Apples Java1.6.

If you use exactly the same build than me (the one I provide with the renderers), it should work but those freeze problems will be completely solved very soon (a few days) when the RC11 is really out. They won't occur with NEWT because the bug was about AWT... If you want to make a fast check, I can update the blueprint of TUER with the latest build; as it uses NEWT, it will show you that it just works :)
89

Okay cool, Iā€™ll just take your word for it for now :slight_smile:



For fullscreen mode I get this, all with the test class modification as written, extracted binaries to root folder and the OSX/Java config I mentioned:

INFO: Selected display mode: 1.024x768x32 @0
Java Result: 143
90

I moved the audio renderer class, make sure you update.



With apples java I get a grey window but the renderer seems to run in the background.

91

I tried to run your example but it used the competitor of JOGL by default, I have probably forgotten something.

92

Change the main class of ā€œjme3test.bullet.TestBrickWallā€ like I posted, should normally run your project, did you update the whole project from svn? I changed some of the build settings and files.

93

I have to extract the binaries in the project root.

94

Ok, I have just copied the JARs containing the native libraries into opt/ and it works. I have changed some code in Application.java so that JOGL is used by default. Of course, I wonā€™t commit that.



@normen, your problem has nothing to do with Mac, some regressions occurred in the JOGL renderers before I tried to port it to JOGL 2.0 the very first time more than a year ago, AWT was not used correctly and now I reproduce exactly the same kind of freeze under GNU Linux.



Moreover, I will update my blueprint of TUER and I would really feel better if you could give it a try in order to confirm that NEWT works flawlessly under Mac 10.6.8. Ardor3D has the most reliable renderer based on JOGL 2.0. If it works, I will have to port a small part of its code to JMonkeyEngine 3.0.

95

:? What you describe should not work. What should work is just extracting the dlls to the project root for the IDE. For command line ā€œjava -jar jMonkeyEngine3.jarā€ (no classpath or other command line params) you have to copy the jogl jars from opt to lib and then have the dll extracted at the right place because the jars with the dlls are not in the manifest, the others in opt are, but with a path to lib ^^. A ā€œtrickā€ to make the jars swappable while keeping the double-clickable jar file.

96

@normen Of course, I will try to find a better solution.



I think Iā€™ve fixed some regressions by reusing some source code from Ardor3D which had been previously used in JMonkeyEngine 2.0. I will commit when it works completely.

97

The freeze is caused by JoalAudioRenderer. If you donā€™t start it, there is no freeze but the display is still blackā€¦ I have just committed a few fixes. The init() method of the animator is called twice for an unknown reason and thatā€™s probably why the OpenGL display does not work yet.

1 Like
98

Okay, Iā€™ll test in case there was commits til I come home and report back :slight_smile:

99

Iā€™m still investigating. I wonder whether initializing everything from the EDT thread is a good idea, maybe this is the root cause of the problem of sound. Something invalidates the canvas and causes the initialization to be done twice, itā€™s annoying.

100
@gouessej said:
I'm still investigating. I wonder whether initializing everything from the EDT thread is a good idea, maybe this is the root cause of the problem of sound. Something invalidates the canvas and causes the initialization to be done twice, it's annoying.


Theres been a few workarounds and similar things due to the problems with lwjgl and canvas integration, I can't exactly say where the lwjgl renderer stands there but I guess its not a good example ^^

Theres also no inherent logic that has to be kept in this really, you don't have to try and adapt, just make what you think would be the cleanest solution / threading.