JOGL Support (JOGL2 that is)

nehon · December 4, 2012, 6:10pm

@gouessej i’ve just updated to last version and i got that exception when I launch the test case

(after a clean and build)

[java]

Exception in thread “jME3 Audio Thread” java.lang.UnsupportedOperationException: Method “alGenAuxiliaryEffectSlots” not available

at jogamp.openal.ALImpl.alGenAuxiliaryEffectSlots(ALImpl.java:597)

at com.jme3.audio.joal.JoalAudioRenderer.initInThread(JoalAudioRenderer.java:217)

at com.jme3.audio.joal.JoalAudioRenderer.run(JoalAudioRenderer.java:105)

at java.lang.Thread.run(Thread.java:722)

[/java]

gouessej · December 5, 2012, 12:43pm

@nehon said:
@gouessej i've just updated to last version and i got that exception when I launch the test case
(after a clean and build)

[java]
Exception in thread "jME3 Audio Thread" java.lang.UnsupportedOperationException: Method "alGenAuxiliaryEffectSlots" not available
at jogamp.openal.ALImpl.alGenAuxiliaryEffectSlots(ALImpl.java:597)
at com.jme3.audio.joal.JoalAudioRenderer.initInThread(JoalAudioRenderer.java:217)
at com.jme3.audio.joal.JoalAudioRenderer.run(JoalAudioRenderer.java:105)
at java.lang.Thread.run(Thread.java:722)
[/java]

Are you under Mac? I know some hardware OpenAL implementations under Mac do not support alGenAuxiliaryEffectSlots. I will ask to the JOAL maintainer how to force the use of OpenALSoft to work around this problem.

Edit.: I have just contacted the maintainer here.

nehon · December 5, 2012, 1:02pm

Nope I’m on Windows 7 64 bit.

gouessej · December 13, 2012, 8:35am

@nehon Ok we will have to force the use of OpenALSoft anyway.

nehon · December 18, 2012, 5:32pm

@gouessej any news on that audio failure?
Maybe I did something wrong?

gouessej · January 3, 2013, 7:22pm

@nehon said: @gouessej any news on that audio failure? Maybe I did something wrong?

No that's our fault, we (JogAmp Foundation) have to provide an option to force the use of OpenALSoft so that you can use most of the features everywhere.

gouessej · January 17, 2013, 10:46pm

There is still a problem of freeze when using the example runner with the AWT display (but not with NEWT).

normen · January 17, 2013, 11:59pm

@gouessej said: There is still a problem of freeze when using the example runner with the AWT display (but not with NEWT).

Yeah, also with the canvas in a swing context (idk if thats the same in jogl effectively).

gouessej · February 5, 2013, 11:52am

The bug 662 of JOAL has been fixed. Use joal.openal.lib=soft if you want to force the use of OpenAL-Soft.

Edit.: I still need to use a more recent version of JogAmp so that you benefit of this fix.

nehon · February 6, 2013, 8:11am

@gouessej said: The bug 662 of JOAL has been fixed. Use joal.openal.lib=soft if you want to force the use of OpenAL-Soft.
Edit.: I still need to use a more recent version of JogAmp so that you benefit of this fix.

I missed that post.
I’ll test it asap
Thanks

gouessej · February 26, 2013, 11:20am

Hi

There are 2 bugs that I have to fix soon so that JMonkeyEngine 3 can work on the Raspberry Pi, noxo provided the fixes but one of them needs some modifications in order to be used only when it is really required in TextureUtil.

Best regards and happy coding.

normen · February 26, 2013, 11:24am

@gouessej said: Hi
There are 2 bugs that I have to fix soon so that JMonkeyEngine 3 can work on the Raspberry Pi, noxo provided the fixes but one of them needs some modifications in order to be used only when it is really required in TextureUtil.

Best regards and happy coding.

Awesome, does that mean you are working towards a renderer that uses your unified API? I guess that would be best at the moment as we kind of lack core renderer dev power atm… Its easier to divide later than to unify for us / jogl non-adepts

The content of this post is meant to be read as a straight information or question without an implicit dismissive stance or interest in having the other party feel offended unless there’s emotes that hint otherwise or there’s an increased use of exclamation marks and all-capital words.

gouessej · February 27, 2013, 2:31pm

@normen said: Awesome, does that mean you are working towards a renderer that uses your unified API? I guess that would be best at the moment as we kind of lack core renderer dev power atm.. Its easier to divide later than to unify for us / jogl non-adepts :)

The existing shader-based renderer (which already works in desktop environments) is usable in embedded environments too (including the Raspberry Pi), it is able to use the unified API between OpenGL and OpenGL-ES. I would like to use the hacks for this device only when I detect it in order to avoid impacting other embedded devices.

I assume that you don’t want me to merge the renderer based on the fixed pipeline with the renderer based on the programmable pipeline (but this is the solution I have just chosen for another engine).

I have forgotten to say that those bug fixes have been committed yesterday, I try to convince a few Raspberry Pi owners to use the official version of JMonkeyEngine instead of noxo’s temporary fork so that they can benefit of our progress.

On the other hand, I don’t know when NEWT Controller API will be ready and I have no WiiMote to test it, I only own several PS2 and GameCube pads.

N.B: I still have to spend a few minutes in updating JogAmp JARs. Rather use OpenAL hardware instead of OpenAL-Soft on the Pi (do the opposite on your computer), see this bug report for more information. It will be fixed soon too

gouessej · February 27, 2013, 11:30pm

I have just committed the latest JARs and fixed some compile errors. Enjoy

normen · February 27, 2013, 11:32pm

@gouessej: Cool. Actually @Momoko_Fan was thinking about using the unified renderer interface but I think he didn’t really get around to have a real look at this yet.

gouessej · February 28, 2013, 9:51am

I think that the shader-based renderer of JMonkeyEngine is quite good, merging it with the renderer based on the fixed pipeline would not ease its maintenance. Using JOGL helpers when there is no support of OpenGL matrices is a good solution for engines that mix calls to the programmable pipeline and calls to the fixed pipeline as it allows to support embedded hardware with a small effort but the big effort leading to a clean shader-based renderer has almost already been done in JMonkeyEngine 3.

I still have to use Raspberry Pi’s hacks only on this device. I will have to prepare the implementation of JoyInput too.

normen · February 28, 2013, 10:03am

@gouessej said: I think that the shader-based renderer of JMonkeyEngine is quite good, merging it with the renderer based on the fixed pipeline would not ease its maintenance. Using JOGL helpers when there is no support of OpenGL matrices is a good solution for engines that mix calls to the programmable pipeline and calls to the fixed pipeline as it allows to support embedded hardware with a small effort but the big effort leading to a clean shader-based renderer has almost already been done in JMonkeyEngine 3.
I still have to use Raspberry Pi’s hacks only on this device. I will have to prepare the implementation of JoyInput too.

Ah, I didn’t mean the fixed and shader renderer, sorry, I didn’t read you right. I meant the GLES and OpenGL (shader based) renderers.

gouessej · March 1, 2013, 10:39am

@normen said: Ah, I didn't mean the fixed and shader renderer, sorry, I didn't read you right. I meant the GLES and OpenGL (shader based) renderers.

Ok, they are implemented in a single class, JoglRenderer XD

nehon · March 3, 2013, 10:47am

@gouessej
Since you did a lot of changes lately I gave it another shot.

I tested TestMultiPostwater again . The good new is that there is no more lag or slow down when several water pools are on screen.
I noticed those issues though :

no sky box (the cube map are not supported yet i guess)
some kind of displacement in the reflection map on water : this one can be tricky because it works fine with LWJGL, and i can’t really see what could mess with the placement in the renderer.
here is a comparison shot for you to understand.

lwjgl
jogl

Don’t mind the missing skybox in the reflection, but as you can see there is some tearing…

vsync is always on no matter what setting is set.
Crash when I input something with the keyboard :
[java]
Exception in thread “main-Display-.windows_nil-1-EDT-1” java.lang.RuntimeException: Within Default-EDT
at jogamp.newt.DefaultEDTUtil$EventDispatchThread.run(DefaultEDTUtil.java:344)
Caused by: java.lang.NoSuchMethodError: com.jogamp.newt.event.KeyEvent.getKeyCode()I
at com.jme3.input.jogl.NewtKeyInput.keyPressed(NewtKeyInput.java:103)
at jogamp.newt.WindowImpl.propagateKeyEvent(WindowImpl.java:2332)
at jogamp.newt.WindowImpl.consumeKeyEvent(WindowImpl.java:2378)
at jogamp.newt.WindowImpl.sendKeyEvent(WindowImpl.java:2250)
at jogamp.newt.driver.windows.WindowDriver.sendKeyEvent(WindowDriver.java:301)
at jogamp.newt.driver.windows.DisplayDriver.DispatchMessages0(Native Method)
at jogamp.newt.driver.windows.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:85)
at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:439)
at jogamp.newt.DisplayImpl$3.run(DisplayImpl.java:370)
at jogamp.newt.DefaultEDTUtil$EventDispatchThread.run(DefaultEDTUtil.java:307)
[/java]
This one is on my end I guess, do I need to extract some native or something like that?

erlend_sh · March 5, 2013, 9:36am

@goussej we could use your help testing this patch for NiftyGUI:
https://code.google.com/p/jmonkeyengine/source/detail?r=10462