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

Initial pull request:
https://github.com/sgothel/jogl/pull/56

This initial version of the LinuxEventDeviceTracker maps the most fundamental keys for use on the RaspPi:
ESC, Space, 0-9, w a s d, enter and the arrow keys.

Duck taped this to my experimental JMonkey3 build and works nicely with Raspberry PI after
found correct /dev/input device.. Really nice work! Wish it has support for USB dual pad
game controller soon :) So long for overhead of X window manager..

noxo wrote

Duck taped this to my experimental JMonkey3 build and works nicely with Raspberry PI after
found correct /dev/input device.. Really nice work! Wish it has support for USB dual pad
game controller soon :) So long for overhead of X window manager..

Why not giving a try to JoglRenderer? The developers of JMonkeyEngine would prefer supporting Raspberry Pi with the same renderer instead of creating another one, really.

@xranby Maybe you could give it a try with your Raspberry Pi so that we get something working for FOSDEM.

gouessej wrote

Why not giving a try to JoglRenderer? The developers of JMonkeyEngine would prefer supporting Raspberry Pi with the same renderer instead of creating another one, really.

Would really like to try that, but there's just not enough hours in day currently. Lets see.. I'm sure Xerxes would do that magic in eye blink (one handed)

noxo wrote

gouessej wrote

Why not giving a try to JoglRenderer? The developers of JMonkeyEngine would prefer supporting Raspberry Pi with the same renderer instead of creating another one, really.

Would really like to try that, but there's just not enough hours in day currently. Lets see.. I'm sure Xerxes would do that magic in eye blink (one handed)

 I am sorry to disappoint you that i am also maintaining this on my free time... so what i can do with my (one handed) arm is reach out to you  and then sum up some suggestions on how you can help out!

noxo you have already prepared some amazing (one handed) demonstrations of what is possible using JogAmp on the RaspberryPi. This is great and i am stunned how you navigate and around the different codebases.

Personally i use the gitk tool to quickly get an overview and manipulate git branch(es) more easily.
Try add a git branch on your initial jme3 svn import with for example the name "unified-renderer" !
Now you can jump from your current git master branch where you happen to do all your experimentation to the new git "unified-renderer" branch easy using
git checkout unified-renderer
and jump back to your old experimental work using
git checkout master

if git complains that your working tree is dirty then use
git stash
or
git checkout on-the-file

so in a nutshell by mastering git branches allows you to navigate around in git time really fast  !

Send small pull requests to the jme3 team or here if you get small fixes working, even fixing a spelling mistake is a cool patch!

Cheers

gouessej wrote

Why not giving a try to JoglRenderer? The developers of JMonkeyEngine would prefer supporting Raspberry Pi with the same renderer instead of creating another one, really.

@xranby Maybe you could give it a try with your Raspberry Pi so that we get something working for FOSDEM.

I will try it in two stages
First i will try load it up on my tegra2 ac100 where i can run eclipse to quickly fix any issues if encountered, then i will try it on the Raspberry Pi.

I will not be able to test it today, but in the near future.

Thank you for your amazing work!

Xerxes Rånby wrote

 and then sum up some suggestions on how you can help out!

yeah, i'll try to align myself in "managed contribution mode"

Xerxes Rånby wrote

gitk and git..

i play with git using eclipse + egit.. and managing branches is quite nicely done in there with few mouse
clicks. of course it will you betray you at some point when trying to do something more complicated.

anyway, let's try get some nice stuff running on RPI with joint effort and schedule that no one will die
in over programming

noxo wrote

Wish it has support for USB dual pad
game controller soon :)

You can try compile JInput it got quite a lot of feature overlap with the LinuxEventDeviceTacker.
git clone http://github.com/JogAmp/jinput.git

The main difference between JInput and the LinuxEventDeviceTracker are:
JInput is using JNI to read from the /dev/input/event* files while the LEDT only uses pure Java.
JInput maps the events to its own JInput specific namespace while the LEDT maps to the NEWT namespace.

Ideally we would like all functionality found in JInput to generate NEWT events directly and preferably using a JNI free approach.

Created branch with initial bits for JME3 unified render.. Got CubeField up and running.. the changing material color thingy (that I thought is a bug in renderer) seems to right behavior in CubeField

https://github.com/noxo/jmonkey-engine-jogl-gles/tree/unified_renderer

I got the unified renderer working.  When I use a solid color with basic Geometry everything works fine.  However when i try to use a texture nothing is visible.  I have tried Unshaded and ColorTextured materials with no avail.  Is there anything working? Or am I just doing something wrong?  I know its loading the pic on the RPi using some test output, so I know thats not it.  Code below is used on the RPi, all the code blocks work on PC machine.

Any help would be appreciated and thanks ahead of time.  =)


Works:

         Quad q = new Quad(14f, 8.75f);
         Geometry g = new Geometry("quad", q);
         g.setLocalTranslation(-7f, -4.375f, -0.0001f);
         Material mat = new Material(assetManager, "Common/MatDefs/Misc/ColoredTextured.j3md");
         mat.setColor("Color", ColorRGBA.Blue);
         g.setMaterial(mat);
         rootNode.attachChild(g);

Works:

         Quad q = new Quad(14f, 8.75f);
         Geometry g = new Geometry("quad", q);
         g.setLocalTranslation(-7f, -4.375f, -0.0001f);
         Material mat_stl = assetManager.loadMaterial("Common/Materials/RedColor.j3m");
         g.setMaterial(mat);
         rootNode.attachChild(g);

Does Not Work:

         Quad q = new Quad(14f, 8.75f);
         Geometry g = new Geometry("quad", q);
         g.setLocalTranslation(-7f, -4.375f, -0.0001f);
         Material mat = new Material(assetManager, "Common/MatDefs/Misc/ColoredTextured.j3md");
         Texture tex = assetManager.loadTexture("Textures/background.png");
         mat.setTexture("ColorMap", tex);
         g.setMaterial(mat);
         rootNode.attachChild(g);

noxo wrote

Duck taped this to my experimental JMonkey3 build and works nicely with Raspberry PI after
found correct /dev/input device.. Really nice work! Wish it has support for USB dual pad
game controller soon :) So long for overhead of X window manager..

I have now improved the pull request to scan all /dev/input/event* files in parallel and add support for hot-swapping while the application is running.
https://github.com/sgothel/jogl/pull/56

It should now be ok to have up to 32 keyboards attached to the Pi and handle them all.  (32 is a hard limit by the maximum number of Linux event device files set by the linux kernel)

I will have to integrate your changes carefully, thank you very much.

gouessej wrote

I will have to integrate your changes carefully, thank you very much.

Yo, patched the "findings" you did @Github, thanks for comments

Dardzull wrote

I got the unified renderer working.  When I use a solid color with basic Geometry everything works fine.  However when i try to use a texture nothing is visible.

I "heard" that you tried also simple texturing test (without JME) which didn't work
that well either?

What kind of test you did? Java+JOGL or C?

Welcome to forums

 

I tinkered with the MovieCube.java a little to do testing and that is working. I also tried using the direct java JOGL Nifty-Gui port, but that seems to have the same issue with textures not showing up (no fonts too).

But I have been trying to dig around in JME3 mostly.  All my testing points to some oddness when applying textures directly with the com.jme3.material.Material or com.jme3.ui.Picture (so far).  Oddly JME3's com.jme3.font.BitmapText object works just fine on the RPi, so I'm trying to dig around in there to see the differences.

I'm too scared to back to C.  heh  its been over 20 years now.

btw I'M FAAAAR from being a great programmer, but I stumble well. ;)

Please look at my latest commits. I have integrated some changes with some refined fixes. There are still some things to do for the alpha and for the profile.

I just wanted to give an update to @noxo and anyone else interested before i crash for the night.

 The latest update to the unified branch killed performance.  Went from 60fps down to 18-20fps.  OUCH!   Not sure what happened.  So, I rolled back to the prior to keep testing as it seems to still have the same basic issues (been testing on both to make sure of this next issue)

I figured out my texture problem and found another.  First on the RPi it seems that a texture needs to be a base of 8 both height and width ... IE 16px by 16px, 32px by 32px, so on and so forth.  Not sure if they only can be 32bit color (still need to look at that).  I'm still walking this one up, so I will let ya know when i hit the limit (or get bored).  Transparency is working on top of it, so I'm kinda happy there.  And my shader is haply chugging away.

However, there is an issue with the texture buffer.  It seems to be taking the first couple of pixels off the left and top then transposing them to the right and bottom.  Going to guess its an indexing issue somewhere in the pipe (api or native).  I've only tested on the armel, so I'm not sure if there is an issue with the armhf yet (but would assume so).  I can try to get a screenshot of the texture displayed if someone needs.

Dardzull, is there the same problem of performance with the official branch (with our latest fixes)?

fyi, Official JME is in Google Code: http://code.google.com/p/jmonkeyengine/

I just merged changes from official JME r10290 to my repo, but official repo
should be used now on. Only benefit on checking stuff from my repo is that
if you're allergic to NetBeans..

One thing that is missing for ARMv6/RPI, is the native lib for jBullet physics
library. "Someone" might give it a try..

noxo wrote

fyi, Official JME is in Google Code: http://code.google.com/p/jmonkeyengine/

I just merged changes from official JME r10290 to my repo, but official repo
should be used now on. Only benefit on checking stuff from my repo is that
if you're allergic to NetBeans..

I'm allergic to Netbeans but I had no time to tinker JMonkeyEngine to make it work in Eclipse. Thank you for the feedback. glAlphaFunc is still present but not called on the RPI.

noxo wrote

One thing that is missing for ARMv6/RPI, is the native lib for jBullet physics
library. "Someone" might give it a try..

Ok. Maybe someone else will take care of that.