[SOLVED] Development on Raspberry Pi 4

superjugy · September 15, 2019, 2:12am

Hi everyone.

I recently bought a RP4 and setup java and intelliJ on it and tried to run my existing game code which is very basic and was getting runtime issues because it could not find the native .so file. After digging around I found that LWJGL recently released version 3.2.3 which has finally added support for arm natives. So I edited my gradle file to depend on the new 3.2.3 version and to my surprise it was able to find the library.

My happiness was short lived though because it soon failed with an error because RP4 does not support OpenGL 3.0. It supports OpenGL ES 3.0 but only OpenGL 2.1. I changed to OPENGL 2.0 but I was getting another error which I have not yet debugged.

I then tried to do a hack and modified the RENDER_CONFIGS in LwjglWindow to have OPENGLES3. But I later found that there is a later check for SUPPORTED_RENDERS in LwjglContext which pretty much forces you to the OpenGL implementations.

I know that JME3 for android uses OpenGL ES 3 so I would assume JME3 is compatible.

I would greatly appreciate if anyone can direct me on how to use OpenGL ES on my raspberry pi 4.

Meanwhile I guess I’ll try to figure out why OPENGL2 is not working.

Thanks everyone.

superjugy · September 15, 2019, 2:42am

Hi,

After debugging, it turns out that the error is due to the format DXT1A not being supported. it is a texture compression that apparently is propietary and raspberry pi drivers don-t support it. I tried to follow this post but still didn’t work:

It might be that it is because I’m running OpenGL 2 instead of OpenGL ES 3. but I don’t know. If anyone could also shed some light here I would appreciate it.

Thanks.

RiccardoBlb · September 15, 2019, 7:53am

s3tc should be available by default in newer mesa
https://www.phoronix.com/scan.php?page=news_item&px=S3TC-Lands-In-Mesa

superjugy · September 15, 2019, 1:59pm

That is weird. I have Mesa version 19 but still no S3TC. Maybe the driver for the Pi doesn’t have it yet? I already posted in their forums asking.

Ali_RS · September 16, 2019, 6:56am

In case this helps, recently OpenGL ES 3 support for JME added through this PR but It is not merged yet and needs testing.

github.com/jMonkeyEngine/jmonkeyengine

Android openGL ES 3 support

jMonkeyEngine:master ← joliver82:android-gl3

opened 12:44PM - 18 Jul 19 UTC

joliver82

+664 -238

Added gles30 and newer functionality for android. All the information at the for…um thread: https://hub.jmonkeyengine.org/t/opengl-es-3-0-and-newer-on-android/41913 Chage list: - Initialize the proper opengl context (2.0, 3.0, 3.1…) - Added Caps for all of the new supported features - Added Instancing as core feature of GLES30 and newer - Properly adding versioning to shaders (#version xxx es) to shaders - Added GLSL320,GLSL310 and/or GLSL300 to most materials depending on the required level for them to work properly - Added depth24 texture usage if hardware supports it - Enabled Geometry shaders and tessellation (3.2 core feature and 3.1 as extension) and fixed compilation errors on the examples - Enabled glBlitFramebuffer - Added GLSL300 to filters not able to work with GLSL100. - Created Glsl300ShaderGenerator to support GLSL300 in shadernodes - Fixed most shader compilation issues (strict type checking, adding OpenGL ES specific extensions, function usage depending on version and some other) - Set default precision to highp solving most filter issues although maybe a little slower. Added specific sampler precision definition for gles300 or newer - Make use of GL_TEXTURE_MAX_LEVEL in GLES300 to avoid black rendering of non complete mipmapped textures - Changed some assets from compressed formats not supported in android to RGB/RGBA depending on the needs so all effects and tests can run also on android - updated precompiled android.jar to have access to newest android API - enabled some other core features of GLES300, GLES310 and GLES320 - Fixed build issues in jme3-android-examples - Added 3D texture and texture array support - Added float texture formats, fixed rgb8 format if having cap rgb8 and fixed glTexImage2D call on AndroidGL - PBRLighting works and any other effect requiring HDR texture formats should work also - Effects and postprocessing - Multisampling Known issues/pending work: - Fixed most issues with shadow rendering in android (GLES 2.0 and GLES 3.0 or better) although some glitches still apear randomly depending on ShadowMode of the nodes and the device - Fixed water filter. Still some rendering glitches in my old redmi3 (gles3.0). The water renders properly but the rest of the scene is overwritten in red. Not reproduced in any other device I've tried

You may like to give it a try

superjugy · September 16, 2019, 1:39pm

That PR looks nice. It seems to be thought for Android though. It is true that the core will have the capabilities, but I am using the jme-desktop dependency since the pi is not exactly a mobile device. The problem is the jme-desktop seems to force OpenGL only. For now I guess I’ll stick to OpenGL 2.0 and see if I can use another uncompressed texture to bypass the S3TC issue.

sgold · September 16, 2019, 3:59pm

Welcome to our community, superjugy.

To properly support RP4, JME would need to define a new com.jme3.system.Platform value for it.

superjugy · September 16, 2019, 4:42pm

That is correct. That is similar to what the LWJGL did. They added a build identifier so now they have linux and linux-arm. Plus they separated the architecture in separate jars. So now the natives-windows jar is 64bits only and the natives-windowsx86 jar is 32 bits only. Same for linux 32 and 64. So yeah we would need to add the linux arm platform, not just android-arm.

I was able to override the dependencies and get the right natives, but my program blowed up when I tried to set the renderer to LWJGL-GLES3 but it doesn’t exist :P. I then tried to force the render by adding it to the list of RENDER_CONFIGS but was stopped because I didn’t add it to the list of SUPPORTED_RENDERERS. So I am not sure if adding the platform or not is needed, or just adding the renderer. LWJGL was not complaining, it was JME.

Is there a reason to have the ARM only in the android package and not the desktop package? Same for GL ES only being in the android package? ARM is coming to more than just mobiles now, I think there is no reason for the desktop package to limit to GL only.

I would love to submit a PR but I am not really that familiar with the internals of JME

superjugy · September 16, 2019, 5:26pm

Just to be clear. The lwjgl3.so was able to be extracted by LWJGL after I overrode the dependencies to LWJGL to 3.2.3. So it appears that it used its own extracto instead of the extractor in the dektop package. Actually, I searched for usages of the extractor in the desktop package and I found none. So I really don’t know what creating a new platform would be for. Sorry if I missed something in the code, as I said I’m new to JME3 internals.

And thanks for the help!

Edit: Small correction. It is not the desktop package that is limiting. it is the jme3-lwjgl3 package. Specifically LwjglContext and LwjglWindow have the supported renderers and render configs Set and Map that don’t allow GL ES. I am not sure if the lwjgl3 package is for desktop only though, since otherwise how would android use GL ES?

sgold · September 16, 2019, 9:54pm

JME uses other native libraries besides lwjgl3, including glfw, openal, jinput, and bulletjme.

JME’s NativeLibraryLoader is definitely used to load bulletjme, but perhaps a basic game doesn’t require physics. I’m unclear how the other native libraries are loaded.

superjugy · September 16, 2019, 11:01pm

Oh, you are right. I was so focused on trying to get the rendering working that I forgot the other parts. And since I’ve not been able to even get that working I hadn’t gotten any other exceptions. Guess compiling on the pi was a more ambitious project than I thought.

sgold · September 16, 2019, 11:32pm

You’re not the only person interested in running JME on a Raspberry Pi:
arm32/64 linux support ?? · Issue #1101 · jMonkeyEngine/jmonkeyengine · GitHub

superjugy · September 17, 2019, 12:21am

Well, If I can be of assistance let me know.

pspeed · September 17, 2019, 12:41am

I would like to be able to run JME on a Pi but not strongly enough to figure out how to make it work.

So just know that there are probably others in the wings hoping someone will figure out how to wire this up properly.

(I have a Pi connected to my TV as a retro-pi console and it would be fun to be able to run JME games on it.)

pankey · September 17, 2019, 3:41am

hi, have you tried an Android image on your raspberry pi 4. because jme apps runs on raspberry pi 3 and orange pi using android, maybe is not what you wanted but at least you could use jmonkey on your pi

superjugy · September 17, 2019, 4:14am

Hi, do you mean installing android instead of raspbian? The whole point was to install intellij and develop my game while I’m far from my windows machine. Installing Android in the pi would defeat this purpose.

Or did you mean to try using the android package and trick it to use GL ES without an actual android activity?

pankey · September 17, 2019, 4:29am

yes, well as a last resort, lol

sgold · September 17, 2019, 4:50am

OK. For starters, what are the values of System.getProperty("os.name") and System.getProperty("os.arch") for your RPI4?

superjugy · September 17, 2019, 11:47am

os.name returns Linux and os.arch returns arm.

Edit: OMG. I don’t know what I did, but somehow my game is running with S3TC. I guess I just needed a restart or something. I don’t get any exceptions. I haven’t added sound and I’m using Nifty-gui.

sgold · September 17, 2019, 5:44pm

Congratulations! Trouble solved?

Feel free to post updates if there are further developments.