LibGDX on RPi

[clicky]

Thanks to @xranby for viewtopic.php?f=81&t=112806 I managed to do a tiny step forward after (re)reading the topic (for n-th time) and provide solution that is slightly easier for us LibGDX developers. I'll do HowTo now and credits at the end:

build.gradle of LibGDX project (top one) has two 'repositories' sections (one in 'buildscript' at the top and one in 'allprojects'). The second one should now(*) have:

Code: Select all

maven { url "http://repository.abstracthorizon.org/maven2/abstracthorizon.snapshot/" }

so it looks like something as:

Code: Select all

    repositories {
        mavenLocal()
        mavenCentral()
        maven { url "http://repository.abstracthorizon.org/maven2/abstracthorizon.snapshot/" }
        maven { url "https://oss.sonatype.org/content/repositories/snapshots/" }
        maven { url "https://oss.sonatype.org/content/repositories/releases/" }
    }

That will add another repo (where I have deployed 'special' version of LibGDX).
Next is for 'allprojects\ext\gdxVersion' to have new value: '1.9.5.rpi-SNAPSHOT'. That's one of the snapshots (currently a build from the source as of week starting on 17th October 2016) of LibGDX with 'bits'(**).

Lastly you need to add:

Code: Select all

compile "com.badlogicgames.gdx:gdx-backend-jogamp:$gdxVersion"

next (after? instead?)

Code: Select all

compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"

Also, as I have only did what @xranby explained in his post - only Jogl would work on RPi you would need another DesktopLauncher - DesktopLauncherJogl (for instance) which should have following in main method:

Code: Select all

        JoglNewtApplicationConfiguration config = new JoglNewtApplicationConfiguration();
        new JoglNewtApplication(new MyGdxGame(), config);

(JoglNewtApplication instead of LwjglApplicationConfiguration.

And - that's all! Export your desktop project as onejar (runnable jar) and copy it to Raspberry Pi. Oh, one more thing - all .so libraries (main gdx library, bullet, gdx-controller, box2d and freetype) are compiled on my RPi which is hf (hardfloat) flavour. I don't mind adding soft if someone desperately needs - but I'll need to set up RPi and/or can always accept help - someone leading me how to/building themselves with my help.

In following days I'll explain what I've done and setup github project with keep all in. In nutshell - I've taken https://github.com/gouessej/libgdx repo, updated it to the latest LibGDX (will endeavour to do pull request for him) then applied xanby's repo over it and then fixed all other libraries and pom files to include those libs (plus a few to/fro RPi rsync-es and manual invocation of build scripts for .so libraries to be compiled). Last is just ensure all .jars aside of standard desktop (Linux/Mac/Windows) jars have included 'xxx-gnu.so' and 'xxx-armgnueabihf.so'.

(*) now as in at the time of the post. Since it is almost automated (aside of plenty of 'paste' button for ssh key password) and I can update it with the latest with hope first release version being 1.9.5 (1.9.5.rpi) and then following LibGDX to next versions.

Credits go to xranby for his efforts and posts here, J. Gousse for maintaining Jogl LibGDX fork(?)/repo and @EntangledLoops for his encouraging posts in original RPi to LibGDX pull request and above linked topic.

Oh, and another last thing - I'll try to pick out changes I've done to xranby's and make a pull request to his work on it. So - stay tuned. Also, the moment I push all to github everyone will be able to repeat all more or less easily!

[littletinman]

This is absolutely awesome! However, I cannot figure out how to include the JOGL backend in my project. Is there a how-to out there you can link to?

[clicky]

It's easy. In <project-root>/build.gradle, after line:
<code>compile "com.badlogicgames.gdx:gdx-backend-lwjgl:$gdxVersion"</code>
add:
<code>compile "com.badlogicgames.gdx:gdx-backend-jogamp:$gdxVersion"</code>

And then in desktop project you can add DesktopLauncherJogl (or whatever your DesktopLauncher is named):
<code>
package com.mygdx.game.desktop;

import com.badlogic.gdx.backends.jogamp.JoglNewtApplication;
import com.badlogic.gdx.backends.jogamp.JoglNewtApplicationConfiguration;
import com.mygdx.game.MyGdxGame;

public class DesktopLauncherJogl {
public static void main(String[] arg) {
JoglNewtApplicationConfiguration config = new JoglNewtApplicationConfiguration();
config.width = 640;
config.height = 480;

new JoglNewtApplication(new MyGdxGame(), config);
}
}
</code>

Then you can start it from Eclipse. Currently it opens borderless window (that needs to be worked on) and you can stop it using stop button in Eclipse. Then I used Export... on Desktop project, selecting Java/Runnable JAR file..., select Launch configuration you use used, gave jar a name and that's it!

You can run it on your computer or RPi with:
<code>java -jar <your-jar-name>.jar</code>

Let me know if you have any issues with it... Maybe I should just create an github test project! Give me a day or two...

[clicky]

Here it is:

https://github.com/natdan/rpi-libgdx-example

Let me know if there are any issues with it.

[Nvreformat]

Here it is:

https://github.com/natdan/rpi-libgdx-example

Let me know if there are any issues with it.

It runs very very slow, perhaps I'm doing something wrong?

Running on raspbian, with xorg and nothing else.

[clicky]

Maybe there is an issue with particular OpenGL driver? Which driver do you have enabled?
I have manually removed (read hacked it) new and kept one that was originally supplied with Raspbian.

It works quite fast for me.

Oh, and I didn't start it under xorg. I might need to try it, too. In the mean time try to run it without xorg started and compare the speeds...

[Nvreformat]

How did you enable the driver you use? Now I installed the full version of raspbian (I had installed the lite one) Tried to run it but it complained about an undefined reference to bcm_host_init(). I read on google that can be fixed by renaming the /opt/vc folder.

After doing that I was able to run the jar on pixel, albeit still slow.

Thanks in advance.

[clicky]

Yes, that would be it. OK, which RPi are you using it on? I have tried example on RPi2 and RPi3 and my home automation LibGDX works on RPi2 happily, but it doesn't use box2d light. I have pizero with external SPI display and I'll try example there.

I am sure that most of LibGDX will work perfectly happily on original RPi, too - and quite fast as well. I do remember a sketchup model my daughter made more than two years ago and I made simple fly through example with it and it managed full 30fps on 1280x1024 (monitor RPi was connected to).

Are you saying that the example is slow or some other piece of LibGDX code you did? If so - could you share it somehow?

[Nvreformat]

It's a RPi 3. Anyway I got it working now. Turns out I had to enable the experimental openGL driver in raspi-config.

Great stuff.

[clicky]

Odd. I don't remember doing it. Good to hear it all works for you!
Out of curiosity - what kind of LibGDX RPi project is that?

[Nvreformat]

I want to make an UI for my car. I've tried using Qt but didn't like it much (plus I don't really like C++ either). Java seemed a nice choice because I didn't need to cross compile for the Pi (which in Qt is a pain in the ass) so I naturally picked libGDX as I'm familiar with it.

[clicky]

Cool! Good luck with it.

[barkholt]

Hi Clicky

First off, thank you for putting this stuff together - it helped me get our game up and running on the PI3 for the first time. I have a few comments and questions

1. You mentioned setting up a github repo - any hope of that appearing? Would love to help out with what I can, getting this to a more stable state.
2. I get instant-freeze of the application if I touch the mouse (no stacktrace), have you run into this?
3. I can't for the life of me get the application running without X (using the /opt/vc driver). Have you had any success with that? If fails during initialization here, claims it can't find a OpenGL ES profile.
4. Any idea what it would take to bring the build up-to-date with libGDX? I would attempt this myself if you could publish your github repo

[clicky]

Sorry for late reply:

"1 You mentioned setting up a github repo - any hope of that appearing? Would love to help out with what I can, getting this to a more stable state."

Yes. I'll take you post as reminder and try to do it as soon as I get couple of hours of free time! My apologies for not doing it while it was fresh.

"2. I get instant-freeze of the application if I touch the mouse (no stacktrace), have you run into this?"

Sorry. No... But I am not running it under X windows. Maybe that's the difference?

"3. I can't for the life of me get the application running without X (using the /opt/vc driver). Have you had any success with that? If fails during initialization here, claims it can't find a OpenGL ES profile."

I've manually removed new ES drivers (don't ask me how - it was more than a year ago) and run everything with old. And not with X windows started. Hopefully that's good enough hint. Oh, also, I didn't try it with the latest Raspbian variant..

"4. Any idea what it would take to bring the build up-to-date with libGDX? I would attempt this myself if you could publish your github repo "

Yes. Reason more I wanted it in github. I would like to move it (for it to be moved) to current stable version of LibGDX, too...

Maybe this Thursday I can snatch moment to start it up. If nothing else just to dump everything I have to cloned repo...

[clicky]

Oh, and it would be nice to set up deploying to some more global Maven repo - if nothing else setup one on github itself...

[barkholt]

Hi Clicky

Sounds great!

Hope you get around to it Would be awesome to have a meaningful place to submit my patches.

[clicky]

Just a short progress report (if not for you but for me): I spend couple of hours yesterday *searching* for the code I built and uploaded to repo. Fortunately just before giving up I found it on RPi I used to build everything (RPi that at that time wasn't connected to the network). It is safe on my laptop right now and I'll put some more effort now knowing that things can be easily lost (especially after I spent half of the time trying to read from another Pi's flaky SD)...

Hopefully I'll do some more tonight/over the weekend and let you know here.

[clicky]

OK. It is back in now. At least some of my work is. Repo is:

https://github.com/natdan/libgdx

and it should follow (at master branch level) original repo https://github.com/libgdx/libgdx

I've created branch called rpi which should be where something like master-rpi should grow from. It contains some snapshot of 1.9.5-SNAPSHOT code which is pushed in my maven repositories. My idea is, that, now I could, for test, create 1.9.5.rpi branch which will start with rpi branch but will merge tag 1.9.5 from the libgdx/libgdx repo to produce stable 1.9.5 maven artifacts to be published. Them, if everything works, we can progress it to master-rpi and move it forward to next stable release (1.9.6?) publish (1.9.6.rpi) from there and then try to keep master-rpi branch updated with master of libgdx/libgdx occasionally publishing next snapshot release. At least that's the idea.

Also, I have quite a few eclipse project and settings file updates I just cannot remember where they are from and I'll commit them in separate (temporary?) branch called rpi-eclipse - which in short term will sit just 'after' rpi branch changes. Feel free to investigate both...

@barkholt if you want to start submitting patches/take over any part of RPi LIbGDX maintenance - just send me pm with your github username and I'll add you to the repo - I would like not to put myself as a bottleneck. Also, do write here or contact me directly if you need help to build rpi libs and jars.

My next tasks (after remind myself how to re-build new version of LibGDX for RPi (on Raspberry Pi itself) is to create libgdx-rpi maven repo on github, too, and publish code there. Let me know if you would need anything else.

[barkholt]

Thanks for getting all that online!

I'll have closer look, and try to get everything building correctly in the coming days.

[clicky]

I did run first build (1.9.5.rpi) and put it in github as a repo (mvn-repo branch) but it didn't work.

Not 100% sure what I did wrong but ran out of time to fix it. At least the process is documented (in my notepad) and I'll look more into it (I have a few ideas what might have gone wrong). When this gets built correctly, we'll (probably) have 1.9.5.rpi,1.9.6.rpi, 1.9.7.rpi and 1.9.8.rpi-SNAPSHOT (at least I am aiming for last two) - all in github (as a repo). It should be relatively straightforward to maintain it along side main stream releases.

[clicky]

Good news: stable version of libgdx 1.9.7.rpi is in new maven repo: https://raw.githubusercontent.com/natda ... /mvn-repo/

If you just add:

Code: Select all

maven { url "https://raw.githubusercontent.com/natdan/libgdx/mvn-repo/" }

to allproject/repositories block (instead of "http://repository.abstracthorizon.org/m ... .snapshot/") and update version to

Code: Select all

gdxVersion = '1.9.7.rpi'

all works!

Now kind of bad news - I've built it on the latest raspbian version and it now insists having it to run. On my previous version of raspbian it is coming up with error:

Code: Select all

java.lang.UnsatisfiedLinkError: /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so)

which I don't know how to fix.

Also, only way I can set it to work on the latest raspbian is cheating with physically copying /opt/vc/lib/libbrcmGLESv2.so over /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0:

Code: Select all

$ sudo mv /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0.disabled
$ sudo cp /opt/vc/lib/libbrcmGLESv2.so /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0

There must be far better way to fix it. If anyone has better way of doing it please share here! References of the problem are here:
https://jogamp.org/bugzilla/show_bug.cgi?id=1290
https://github.com/anholt/mesa/issues/2 ... -184451181

[clicky]

And 1.9.8.rpi-SNAPSHOT as well! ... which is current state of libgdx/libgdx master branch.

[barkholt]

Awesome work!

During my initial attempts at getting your 1.9.3 branch running on the latest Raspbian, I ran into the same problems with the GPU drivers. It was a bit unclear to me who is to 'blame' for the problems, and thus who is the right part to fix the issue (Raspbian? Jogl?).

Your workarounds fit my personal use cases just fine, so thank you for documenting them.

[clicky]

You're welcome. If you want to contribute anything to RPi 'fork' - just create an issue on github and I'll add you as an collaborator. I am yet to post instructions how to build everything on RPi itself. This time I did take notes so I (or anyone else) can recreate my builds more easily.

[msx80]

Hi there! I'm very interested in making this run too, and i'm happy to help if it's needed!
I've just made some tests, i was able to run your example on https://github.com/natdan/rpi-libgdx-example , it worked great after "disabling" one copy of the GLES as you reported.

Now i'm trying to run the 1.9.8.rpi-SNAPSHOT version as per your latest post, i get your same error:

Code: Select all

Exception in thread "main" com.badlogic.gdx.utils.GdxRuntimeException: Couldn't load shared library 'libgdxarmgnueabihf.so' for target: Linux, 32-bit
        at com.badlogic.gdx.utils.SharedLibraryLoader.load(SharedLibraryLoader.java:125)
        at com.badlogic.gdx.utils.GdxNativesLoader.load(GdxNativesLoader.java:33)
        at com.badlogic.gdx.backends.jogamp.JoglNativesLoader.load(JoglNativesLoader.java:27)
        at com.badlogic.gdx.backends.jogamp.JoglApplicationBase.<init>(JoglApplicationBase.java:53)
        at com.badlogic.gdx.backends.jogamp.JoglNewtApplication.<init>(JoglNewtApplication.java:49)
        at net.lugato.fc.desktop.TestDesktopLauncherJogl.main(TestDesktopLauncherJogl.java:14)
Caused by: com.badlogic.gdx.utils.GdxRuntimeException: java.lang.UnsatisfiedLinkError: /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so)
        at com.badlogic.gdx.utils.SharedLibraryLoader.loadFile(SharedLibraryLoader.java:321)
        at com.badlogic.gdx.utils.SharedLibraryLoader.load(SharedLibraryLoader.java:121)
        ... 5 more
Caused by: java.lang.UnsatisfiedLinkError: /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so: /usr/lib/arm-linux-gnueabihf/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so)
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1938)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1821)
        at java.lang.Runtime.load0(Runtime.java:809)
        at java.lang.System.load(System.java:1086)
        at com.badlogic.gdx.utils.SharedLibraryLoader.loadFile(SharedLibraryLoader.java:327)
        at com.badlogic.gdx.utils.SharedLibraryLoader.loadFile(SharedLibraryLoader.java:296)
        ... 6 more

Have you made any progress after this? Looking at the error messages, it looks like there's some mismatch on library versions. The error originates from the library in /tmp/libgdxpi/8e12763a/libgdxarmgnueabihf.so, which, given the path, i assume is something that's unzipped on the fly by libdgx, and so probably contained in your distribution (am i correct?)

Googling for CXXABI_1.3.9, i found some other cases, some people suggest dist-upgrading (ok, no thanks), other to use a different GCC version. GCC docs says:

This means the linker found /usr/lib/libstdc++.so.6 but that library belongs to an older version of GCC than was used to compile and link the program a.out (or some part of it). The program depends on code defined in the newer libstdc++ that belongs to the newer version of GCC, so the linker must be told how to find the newer libstdc++ shared library.

Perhaps the .so libraries you supplied in the maven repository were made with a different raspbian and a different libstdc?

I'm using RetroPie btw (based on Raspbian).

PS Thanks for your awesome work!