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

Why do you claim the problem comes from JMonkeyEngine? NewtKeyInput works very well while NEWT generates events when a key is pressed or released.

sgothel have been thorough and fixed the LinuxEventDeviceTracker to send the correct released events.
http://jogamp.org/git/?p=jogl.git;a=blobdiff;f=src/newt/classes/jogamp/newt/driver/linux/LinuxEventDeviceTracker.java;h=2c0e6d3dd5163b80b21de9e5fac15f8d499245cc;hp=5efce2524a9ac343d2a9e2c7ac4bab826252a149;hb=85338858f5c58694fa88e77df1386d0556887944;hpb=a40ee817a3bd537b0de7018772b0835f995a1bed

The only difference between the NEWT events generated by the Rasberry Pi and X11 that I am aware of is that the Raspberry Pi currently always sends the NEWT VKey and Printable char all in uppercase. I guess this might confuse JMonkeyEngine that expects the 'w' to be lowercase when Raspberry currently sends a 'W'.

TODO: We can fix this by using a "unicode to lowercase" function when the "shift" modifier is not in use for all "KeyEvent.isPrintableKey" VKey's.

TODO 2: We need to figure out how to do proper key-map mapping on the Raspberry Pi, language key-map mapping is usually performed inside the X11 server, and we dont use the X11 server on the pi for keyboard input.

I looked in to the implementation of LinuxEventListener, it basically spawns a thread for each event file found. These threads are blocked by the FileInputStream.read()

I am trying to implement a Joystick Implementation for JMonkey. I am running in to  performance issues with the JMonkey code with settings.setUseJoysticks(true);

My application has a single quad object on the screen. On the RaspberryPi it runs at 60FPS with out the Joystick Implementation.

If the settings.setUseJoystick(true) is called - the frame rate drops to 15FPS.

Just to eliminate possible causes for this performance drop. I created a dummy JoyInput Implementation - this just had an update method similar to NewtMouseInput.java - all other methods were just skeleton to satisfy compilation. i.e this JoyInput will get loaded in to JMonkey InputHandler but it will never generate any events.

In this scenario, the frame rate is  25FPS.  I have disabled all logging just to measure the FPS.

The only difference between not using Joystick and the above dummy implementation is the call to update method in the Joystick implementation.

I would like to see whether KeyInput and MouseInput implementation results in such performance drops. As of now, I assume that JMonkey code doesnot call update methods in the NewtKeyInput or NewtMouseInput because no key event reaches the application.

Any thoughts on what possibly causes this drop in frame rate from 60 to 25 for calling a dummy update method 10 times per second.

What do you do exactly in this update method?

This the update method - the eventQueue is an ArrayList

In the dummy implementation of  JoyInput the eventQueue never gets populated so the for loop never executes - with this FPS is 25

In the concrete implementation the eventQueue gets populated by a separate thread - with this the FPS is 15

public void update()
        {
                 synchronized (eventQueue) {
                    eventQueueCopy.clear();
                    eventQueueCopy.addAll(eventQueue);
                    eventQueue.clear();
                }

                int size = eventQueueCopy.size();
               // logger.log(Level.INFO,"Queue size "+size);
                float value = 0;
                for (int i = 0; i < size; i++)
                {
                pevent = (PropertyChangeEvent) eventQueueCopy.get(i);
                String name = pevent.getButton().name();
                //logger.log(Level.INFO,name);
                btn = vjt.getButton(name);      
                if(btn!=null)
                {
               
                evt = new JoyButtonEvent(btn, pevent.isPressed());
                    listener.onJoyButtonEvent(evt);
                }
                else
                {
                if (name.equalsIgnoreCase(RemoteButtons.DPadL.name())||(name.equalsIgnoreCase(RemoteButtons.DPadD.name())))
                {
                value = -1f;
                }
                else
                {
                value = 1f;
                }
                if (name.equalsIgnoreCase(RemoteButtons.DPadL.name())||(name.equalsIgnoreCase(RemoteButtons.DPadR.name())))
                {
                laxis = vjt.getAxis("POV_x") ;
                }
                else
                {
                laxis = vjt.getAxis("POV_y") ;
                }
                axevt = new JoyAxisEvent(laxis,value);
                listener.onJoyAxisEvent(axevt);        
                }
               
                }
               
        }

Which JVM do you use in combination with OpenJDK on the Pi?

Try re-run your code with JamVM and CACAO VM.
java -jamvm -version
java -cacao -version
java -version (by default this gives you the zero jvm that is the slowest to use on the pi)

JamVM is available with OpenJDK 6 and 7.
Cacao JVM is currently only available with OpenJDK 6.

I have tried running it with jamvm  as well as zerovm.

In both of them the frame rate is more or less the same.

In JamVM - I get 18FPS  -  An app with my Joystick implemented
in ZeroVM - I get 15FPS

In JamVM - I get 25FPS -  Same app with Joystick disabled
In ZeroVM - I get 22FPS

The only difference between jamvm and zerovm is in the startup time.

ZeroVM takes more than 45 seconds for the graphics to appear. jamvm starts the screen in 20 seconds.

krishnak wrote

public void update()
        {
                 synchronized (eventQueue) {
                    eventQueueCopy.clear();
                    eventQueueCopy.addAll(eventQueue);
                    eventQueue.clear();
                }

Maybe you have a lot of contention on the synchronized statement? Just for testing, try to remove that, it will not be thread safe and all that but just to see. I've hade some bad luck with performance using synchronized in some specific situations. Usually not because of the synchronized keyword as such but because of contention.

The synchronized block is present in MouseInput as well as KeyInput implementations it doesn't appear to reduce performance there. To remove contentions, I am not starting my thread implementation which feeds this queue. The only code which is using this synchronized block is the UI thread(JMonkey) looking for events.

Dardzull has kindly checked my code on his RaspberryPi - Apparently he is using the Armel image with Sun's Java - it runs at 60 FPS
 on his machine.

Same code On mine which runs in Raspian wheezy (Hard float) and Open JDK 7 (with and with out jamvm ) I am only getting 25FPS

I downloaded the Sun JDK 8 EA and voila with that the same app which had 25FPS on the PI, is now running at 60FPS - this is with my Joystick implementation as well.

You can use the Hotspot Oracle JDK 8 EA JIT in combination with the OpenJDK 7 classes and launchers.

benefits:
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=238135#p238135

setup instructions:
http://www.raspberrypi.org/phpBB3/viewtopic.php?p=238541#p238541

I have managed to get the native Bullet compiled for Raspberry Pi.

The standard JMonkey Brick wall application used to be at 0 FPS with JBullet.

With native code, I get a maximum of 20 FPS @ 1080P - there is no difference even if I run it at 800x480

In my opinion it is still slow, FPS is proportional to the number of bricks on screen.

However even with No bricks on screen - i.e after knocking off all the bricks from the floor, the FPS doesn't increase beyond 20.

If any one wants it to be uploaded to Jmonkeycode base, I can share it.


Edit: I tried reducing the physics accuracy to 1/20 with that game FPS maxes to 30FPS but it doesn't stay put.

With reference to the ASDW key events in JMonkey and Raspberry Pi, I wanted to give an update.

Case 1:
If I extend a SimpleApplication and enable FlyCam.

ASDW keys move the camera, when I use JOGL on a PC.

Code does not have any additional listeners.

The same code when executed on a Pi,  ASDW keys DO NOT move the camera.

Case 2:

If I extend a SimpleApplication and DISABLE FlyCam.

this time the  code has additional listeners and Mapping as below

inputManager.addMapping("Left", new KeyTrigger(KeyInput.KEY_A));
    inputManager.addMapping("Right", new KeyTrigger(KeyInput.KEY_D));
    inputManager.addMapping("Up", new KeyTrigger(KeyInput.KEY_W));
    inputManager.addMapping("Down", new KeyTrigger(KeyInput.KEY_S));
    inputManager.addMapping("Jump", new KeyTrigger(KeyInput.KEY_SPACE));
    inputManager.addListener(this, "Left");
    inputManager.addListener(this, "Right");
    inputManager.addListener(this, "Up");
    inputManager.addListener(this, "Down");
    inputManager.addListener(this, "Jump");

With this - the ASDW keys move the camera position both in Raspberry Pi as well as on PC

krishnak wrote

With reference to the ASDW key events in JMonkey and Raspberry Pi, I wanted to give an update.

Case 1:
If I extend a SimpleApplication and enable FlyCam.

ASDW keys move the camera, when I use JOGL on a PC.

Code does not have any additional listeners.

The same code when executed on a Pi,  ASDW keys DO NOT move the camera.
...

I have sent a JOGL pull request to implement a LinuxEventDeviceTracker shift modifier in order to allow the RaspberryPi to generate lower-case key presses.
https://github.com/sgothel/jogl/pull/62
I hope this change will fix the FlyCam input.

What happened to this project? I just got a Raspberry Pi and noted that lots of improvements have been made to Raspbian in the past several months.

The Pi could really use some games, and I think it has a lot of potential.

I'll "refresh" the JOGL backend of LibGDX and if there is any problem with the Raspberry Pi, maybe Xerxes will be able to give us some help.

Hi

I've updated the whole backend, it should work very well now:
https://github.com/gouessej/libgdx/tree/master/backends/gdx-backend-jogl

gouessej wrote

Hi

I've updated the whole backend, it should work very well now:
https://github.com/gouessej/libgdx/tree/master/backends/gdx-backend-jogl

Thank you gouessej!
I have updated the backend some more, some notable changes:
* fixed keyboard input
* fixed libgdx 3D demos using shaders. libgdx examples and shaders currently only work on GLES2 and GL2 OpenGL contexts, thus make sure we request an libgdx backward compatible context if possible.
* updated support for libgdx LifecycleListeener's
* working on removing all jar binarys from the jogl backend, this makes the jogamp libgdx jogl backend much easier to maintain. JogAmp jars are now downloaded from jogamp.org during the libgdx ant build. You can fetch all required jars upfront by running
cd libgdx
ant -f fetch.xml
* fix various NPE observed at startup/shutdown while running the libgdx tests.

https://github.com/xranby/libgdx/commits/jogamp-jogl-backend

Cheers
Xerxes

Thank you, I'll get your changes :)

gouessej wrote

Thank you, I'll get your changes :)

I have added Jogl demo launchers to all the libgdx demos: game on!
https://github.com/xranby/libgdx/commit/fa42c889b298af9b06ffaba739e813b5a9d2a93a

I have merged rudimentary JDK 8 ARM GNU/Linux support into libgdx master.
https://github.com/libgdx/libgdx/commit/8f83f0f4449d5f4e71ba3771fa151e9f40e84721
It is now possible to bundle libgdx ARM GNU/Linux natives inside libgdx-natives.jar using the following native names:
JDK 8 ARM systems will try to load:
lib*armgnueabi.so -> 32bit ARM GNU softfp EABI
lib*armgnueabihf.so -> 32bit ARM GNU hard float EABI
lib*armandroideabi.so -> 32bit Android EABI

JDK 6/7 ARM systems will try to load:
lib*arm.so -> 32bit ARM unknown ABI.