JOGL 2.0 (OpenGL/OpenGL-ES) backend for LibGDX

gouessej i tested your new gdx jogl awt code for use by the JoglAppletTest and SwingJoglTest.

The applet gets a strange offset inside the appletviewer:


The SwingJoglTest got a strange clipping, not that in this test three parrallel libgdx apps are supposed to be running:

The SwingJoglTest above is supposed to look like this:


When you resize the  SwingJoglTest you notice that the clipping reveal more of the application when using a smaller window:

I'll try to fix the applet support soon, thank you for the screen capture.

I have prepared a new pull request:
https://github.com/gouessej/libgdx/pull/3

This pull request add the following features:
* Include jogamp native jars for linux-arm support
* ant build fix, dist now include jogamp, gdx-backend-jogl and gdx-joal jars.
* eclipse runnable jar export using gdx-backend-jogl
* Initial GL2ES1 support.

https://github.com/gouessej/libgdx/pull/4

This fix enable all libgdx OpenGL ES 1 games and tests to work on ARM GNU/Linux systems.
Test output below:

Tegra 2 AC100:



Broadcom VC IV Raspberry Pi:
https://twitter.com/xranby/status/290600190241566721/photo/1 - Pax-Britannica
https://twitter.com/xranby/status/290601186254540800/photo/1 - UITest

I've accepted your pull requests, thanks. I have to fix applets as soon as possible. In the worst case, we'll have to use Java Web Start until this feature works.

gouessej wrote

I've accepted your pull requests, thanks. I have to fix applets as soon as possible. In the worst case, we'll have to use Java Web Start until this feature works.

Thank you!

I will now switch focus to the JogAmp codebase.
The JOGL LinuxMouseTracker, that we use for NEWT mouse input on the Raspberry got inverted Yaxis demonstrated in this video:
 http://www.youtube.com/watch?v=C4wiM9wDzyY
The mouse buttons/scroll wheel also do not work as intended.
While at it I will look into adding some sort of keyboard input by hitting the /dev/ files from console.

JOAL is working sub-optimal on the Pi as well, it play sounds but it is all CPU driven.
The known way to get hardware accelerated sound playback is to use OpenMax IL. There exist some example code in /opt/vc/src on the Raspbery Pi on how to use this API. This would require some heavy patching of OpenAL-soft in order to implement an OpenMax IL backend.

Xerxes Rånby wrote

This would require some heavy patching of OpenAL-soft in order to implement an OpenMax IL backend.

Don't forget that I still need a flag to favor OpenAL-Soft (otherwise I won't be able to run some demos with JMonkeyEngine 3).

2013-01-14 13:42, gouessej [via jogamp] skrev:
>
>     Xerxes Rånby wrote
>     This would require some heavy patching of OpenAL-soft in order to implement an OpenMax IL backend.
>
> Don't forget that I still need a flag to favor OpenAL-Soft (otherwise I won't be able to run some demos with JMonkeyEngine 3).

I need more input from you on your system set-up and possible suggestions on how you want this flag to operate.
Please create a new JMonkeyEngine 3 forum/mail thread to keep track on which git tree to use in order to test jME3 in combination with JOGL 2.
I would like to test this branch.

OpenAL-soft is a regular libopenal there is no special switches needed to use it.

Try install your linux systems libopenal package, to my knowledge all linux systems libopenal is a package build of openal-soft.
Premade Win32 and Win64 openal-soft binaries are available from: http://kcat.strangesoft.net/openal.html

When we get the JogAmp Jenkins builders to build and bundle openal-soft then we can look into only load our own build of libopenal.
To my knowledge all bug-reports we have received for JOAL during the last half year boil down to problems/missing extention functionality with the system installed libopenal.
I think it is a good idea to only use our own more up to date openal-soft builds in order to fix these kind of issues when they are available.

Cheers
Xerxes

I already wrote a bug report about that problem. I just want a mean of prioritizing OpenAL-Soft when both OpenAL hardware implementation and OpenALSoft are available.

gouessej wrote

Xerxes Rånby wrote

This would require some heavy patching of OpenAL-soft in order to implement an OpenMax IL backend.

Don't forget that I still need a flag to favor OpenAL-Soft (otherwise I won't be able to run some demos with JMonkeyEngine 3).

BTW - a bit offtopic - is there version of JMonkeyEngine3 with JOGL ES backend, I was checking the implementation and current
ES looks like Android only?

Tried myself implementing Monkey3 JOGL ES by copy-pasting Android ES with small modifications.. and basic things seems to work
quite nicely now.. even on Raspberry PI + OpenJDK 7 CubeField seems to run with acceptable framerate..  same input issues as with libGDX thought..

https://twitter.com/enoksokoivisto/status/291315847618756608/photo/1

The renderer based on the programmable pipeline should work on ES2 as it uses methods in GL2ES2 except glAlphaMask. Why not trying to use this renderer instead of starting from the one for Android (that uses AndroidGL)? If you succeed, I will be able to integrate your contributions (with correct attribution of course).

Edit.: Actually, most methods come from GL2GL3. In my humble opinion, it would be better to use JoglRenderer instead of creating a third renderer.

noxo wrote

...  same input issues as with libGDX thought..

https://github.com/sgothel/jogl/pull/55
This JOGL pull request fixes the mouse input issue when using the JOGL NEWT LinuxMouseTracker on the Raspberry Pi.

noxo can you check
ls -la /dev/input/mice
on your Raspberry Pi and make sure that this file is readable for your user.


I have also started an JogAmp-2.0.2 libgdx branch.
https://github.com/xranby/libgdx/tree/JogAmp-2.0.2
This will update gdx-backend-jogl to handle the recent mouse-wheel API change found in the imminent new JogAmp release.

gouessej wrote

The renderer based on the programmable pipeline should work on ES2 as it uses methods in GL2ES2 except glAlphaMask. Why not trying to use this renderer instead of starting from the one for Android (that uses AndroidGL)?

Yeah, one renderer, which just forks correctly on GLES capabilities/version would be much better solution. I did just blindly gone into copying of Android implemention, without checking current JOGL renderer.. looks like it wouldn't require that much effort to work on GLES too..

Pushed this two renderer hack into https://github.com/noxo/jmonkey-engine-jogl-gles .. but like you said eventually it's probably wrong way to go :)

Xerxes Rånby wrote

https://github.com/sgothel/jogl/pull/55
This JOGL pull request fixes the mouse input issue when using the JOGL NEWT LinuxMouseTracker on the Raspberry Pi.

Will try this out.. looks like this could fix most of issues, if mouse button down state were not reseted :)

noxo wrote

gouessej wrote

The renderer based on the programmable pipeline should work on ES2 as it uses methods in GL2ES2 except glAlphaMask. Why not trying to use this renderer instead of starting from the one for Android (that uses AndroidGL)?

Yeah, one renderer, which just forks correctly on GLES capabilities/version would be much better solution. I did just blindly gone into copying of Android implemention, without checking current JOGL renderer.. looks like it wouldn't require that much effort to work on GLES too..

Pushed this two renderer hack into https://github.com/noxo/jmonkey-engine-jogl-gles .. but like you said eventually it's probably wrong way to go :)

I have no Raspberry Pi, I can't test. However, GL2GL3 extends GL2ES2, the only problem comes from the method in GL2 (glAlphaMask). You can skip this call is the current GL isn't compatible with isGL2ES2(), use getDefault() instead of getMaxFixedFunc(true), add the JARs containing the native libraries for ARM if they aren't already provided and it should work.

noxo wrote

Would be nice to start work on that console based input listener...

I have started some work on a NEWT LinuxEventDeviceTracker, the keyboard parser is about done but it needs testing.
https://gist.github.com/ec17597f5c079708ce72

java -cp jogl/build/jar/jogl-all.jar:gluegen/build/gluegen-rt.jar jogamp.newt.driver.linux.LinuxEventDeviceTracker

This tracker is intended to parse all of the Linux /dev/input/event* files but in the version posted here it currently only track one hardcoded file name.

The event dev files are nice they contain events from all keyboard, mouse wheel, mouse, joystick, audio jack connections, power buttons etc connected to a linux system, all using the same.. easy to parse event interface!
http://www.kernel.org/doc/Documentation/input/input.txt
http://www.kernel.org/doc/Documentation/input/event-codes.txt

On 01/17/2013 04:01 AM, Xerxes Rånby [via jogamp] wrote: Great stuff!

Regarding daemon thread lifecycle:
  - start @ 1st device nativeOpen
  - stop @ last device nativeClose

.. hence we need a NEWT device association, i.e. impl.,
but I guess we already have that due to RaspPi.

Yeah, and then the looong discussion about virtual keycodes,
i.e. independent of current keymap - see Bug 641
  <https://jogamp.org/bugzilla/show_bug.cgi?id=641>

~Sven

Xerxes Rånby wrote

I have started some work on a NEWT LinuxEventDeviceTracker, the keyboard parser is about done but it needs testing.
https://gist.github.com/ec17597f5c079708ce72

Nice, never thought that this could be implemented in such easy way by just reading /dev/input.. i wonder if there's any issues with input device that creates a lot of "samples" to synchronize/catchup everything.

Worked nicely on x86 debian in X and console.. for some reading bytes out via StructAccessor didn't work (OOB) but had to read right away from ByteBuffer. Anyway, will try to play with RPI and this later :)

Sven Gothel wrote

On 01/17/2013 04:01 AM, Xerxes Rånby [via jogamp] wrote:
>     noxo wrote
>     Would be nice to start work on that console based input listener...
>
> I have started some work on a NEWT LinuxEventDeviceTracker, the keyboard
> parser is about done but it needs testing.
> https://gist.github.com/ec17597f5c079708ce72
>

Great stuff!

Regarding daemon thread lifecycle:
  - start @ 1st device nativeOpen
  - stop @ last device nativeClose

.. hence we need a NEWT device association, i.e. impl.,
but I guess we already have that due to RaspPi.

I will activate this code soon for the RaspPi by changing :

Xerxes Rånby wrote

------- src/newt/classes/jogamp/newt/driver/bcm/vc/iv/WindowDriver.java -------
index 21fbea9..bdef8e6 100644
@@ -37,6 +37,7 @@ import javax.media.nativewindow.util.Insets;
 import javax.media.nativewindow.util.Point;
 
 import jogamp.newt.WindowImpl;
+import jogamp.newt.driver.linux.LinuxEventDeviceTracker;
 import jogamp.newt.driver.linux.LinuxMouseTracker;
 
 public class WindowDriver extends WindowImpl {
@@ -76,11 +77,13 @@ public class WindowDriver extends WindowImpl {
         }
         windowHandleClose = nativeWindowHandle;
         addWindowListener(LinuxMouseTracker.getSingleton());
+        addWindowListener(LinuxEventDeviceTracker.getSingleton());
         focusChanged(false, true);        
     }
 
     protected void closeNativeImpl() {
         removeWindowListener(LinuxMouseTracker.getSingleton());
+        removeWindowListener(LinuxEventDeviceTracker.getSingleton());
         
         if(0!=windowHandleClose) {
             CloseWindow(windowHandleClose, windowUserData);


 

Sven Gothel wrote

Yeah, and then the looong discussion about virtual keycodes,
i.e. independent of current keymap - see Bug 641
  https://jogamp.org/bugzilla/show_bug.cgi?id=641

I agree computer keyboard keycode namespace(s) are really a messed up.
We have so many of them:

* The USB keycode namespace. (the codes the HID keyboards actually send)
http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf
- These codes are keymap independent!

* The Linux event keycodes namespace that is a variant of the USB keycode namespace. (the codes i get from the Linux events)
/usr/include/input.h
http://www.kernel.org/doc/Documentation/input/input.txt
http://www.kernel.org/doc/Documentation/input/event-codes.txt
- These codes are also keymap independent!

* The operating GUI system specific keycode namespace (X11, Windows, MacOS, Android)
- These codes have passed through an keymap transformation ...

* AWT namespace
- These codes have passed through an keymap transformation (based on X11, Windows, MacOS...

* NEWT VK namespace
- These codes have passed through an keymap transformation based on which NEWT backend generated the code. needs fixing.
https://jogamp.org/bugzilla/show_bug.cgi?id=641

* The Unicode namespace
- These codes are keymap independent!

* The ASCII character namespace
- avoid...

so yeah.. through and careful thinking is needed to get the same behaviour and output across devices.

Suggestion:

keySym == a unique index for a key or button.
I suggest that we use the HID Hut1_12v2.pdf namespace for keySym
These maps nicely with input device keys.

keyCode == similar to keySym but re-arranged according to system keymap in use. (unclear how this conversion is done)

keyChar == printable character on screen.
I suggest that we use the Unicode name-space for keyChar.
These maps nicely with fonts.

My head already spins thinking about these codes  so.. if someone happens to be an expert on computer input system code namespaces please chip in.