Libp5x examples - Processing, LWJGL, Gradle and Java 11+ modules

I’ve just started putting together a few Gradle-based examples for using libp5x (as published on Maven Central). This is the fork of Processing 3.5.3 used inside PraxisLIVE v5+. It’s adapted to use LWJGL for OpenGL rendering, support running on Java 11+ and split into Java modules. The Gradle scripts show use of a data folder and also a libs folder for adding Processing libraries (PeasyCam in this case).

Early days on these, and I haven’t tested the Gradle scripts on all OS or the Pi yet (although PraxisLIVE is tested across all so hopefully works). Hope they’re of use to a few more people around here! :smile:

4 Likes

Works for me on my Archlinux (AMD64) box, but I get following runtime error on my ManjaroArm (–aarch64) RaspberryPI4:-

> Task :run FAILED
GLFW error 65543: GLX: Failed to create context: GLXBadFBConfig
java.lang.NullPointerException
        at org.lwjgl.system.Checks.check(Checks.java:100)
        at org.lwjgl.glfw.GLFW.glfwSetWindowPos(GLFW.java:2135)
        at processing.lwjgl.PSurfaceLWJGL.initWindow(PSurfaceLWJGL.java:471)
        at processing.lwjgl.PSurfaceLWJGL.initFrame(PSurfaceLWJGL.java:232)
        at processing.core.PApplet.initSurface(PApplet.java:11059)
        at processing.core.PApplet.runSketch(PApplet.java:10946)
        at processing.core.PApplet.main(PApplet.java:10675)
        at com.codelerity.libp5x.esfera.Esfera.main(Esfera.java:105)

FAILURE: Build failed with an exception.

1 Like

Thanks. Good to know. Try adding PLWJGL.profile = 2; as the first line of Esfera::main Downside of the LWJGL backend at the moment is inability to automatically detect what OpenGL(ES) profiles are available. I forgot that PraxisLIVE has code to default to OpenGLES on Arm.

@neilcsmith fixed with:-

public static void main(final String[] args) {
	processing.lwjgl.PLWJGL.profile = 2;
	PApplet.main(new Esfera());
 }

Something weird going on seems to require fully qualified address for compiling, but when I examine code after running it was PLWJGL.profile = 2;, I am not familiar with gradle but does it keep some funny code history?

1 Like

Great! Should have worked with import processing.lwjgl.PLWJGL; too.

I’m not a huge fan of Gradle myself, but it was the easiest way to set up support for data and libs folders, and the required JVM arguments. It also builds distributions with launcher scripts. It will cache things at times unless you do gradle clean, or gradle clean run.

How does LWJGL compare to P2D/P3D JOGL? Also – I may have asked this before – how come LWJGL hasn’t been included in Processing 4?

Under more active development, nicely modularized, less abstraction and more suited to Java 11+ at the moment.

libp5x isn’t tied to LWJGL. One change I made is to abstract the the OpenGL renderers, so a JOGL option could just be a case of switching dependencies. But not until JOGL has an up-to-date release.

Well there’s a million dollar question! :smiley: There seemed some reluctance to add the necessary main thread API into PApplet to make it viable. This is another change in libp5x, although changes are deliberately kept minimal to keep compatibility.