lwjgl | LWJGL for Raspberry Pi

You selected the wrong natives in the LWJGL customizer for your CPU architecture. You selected macOS x64, however M1 is not x86 but arm. The current* LWJGL release 3.2.3 does not support macOS arm. You have to use the 3.3.0 Early Access version on the LWJGL customizer and then select the macOS arm64 native.

EDIT:

* LWJGL 3.3.0 is already released and hence one does not necessarily need to choose "Early Access" version anymore. Both x64 and arm natives can now be selected in a stable release version of LWJGL.

You are requesting OpenGL 3.3 core (the "3.3" is not the LWJGL or GLFW version 3.3 - it is the OpenGL context version you are requesting), which does not have the deprecated OpenGL functions available, that you are trying to use - glBegin and glVertex2f.

The error message hints at that:

No context is current or a function that is not available in the current context was called.

There is also a misunderstanding. To clarify, the following comments in your code are misleading/wrong:

You are using a very very old and outdated version of LWJGL, namely version 2, together with a more modern Java/JRE version 15 shipped with Eclipse.

What will solve your issue is when you use an explicit older Java/JRE version, preferably OpenJDK 8, as that is guaranteed/tested to work with LWJGL 2. So, download an OpenJDK 8 and instruct Eclipse to use that to run your application.

It is very likely that LWJGL 2 simply does not work with any Java/JRE version higher than 8, as that is the last version tested against the last LWJGL 2 release version. While it is true that old Java code should work with newer JRE/Java versions, this promise breaks in the event of native code, which LWJGL 2 contains a lot of in order to interop with the JRE and especially its JAWT/AWT library.

So, a few dates on a timeline to get what you are doing into perspective:

• Java 8 release date: March 2014
• Publish date of the YT tutorial you are watching: July 2014
• The last LWJGL 2 release (2.9.3): January 2015 ...
• Java 15 release date: September 2020

Please keep in mind that tutorials as well as software/library versions do get outdated and eventually cease to work by becoming incompatible with an advancing/newer runtime and its provided/dependent libraries.

Again: LWJGL 2 is completely end of life for more than seven years now and will not be improved/fixed or otherwise worked on. The next version is LWJGL 3 (first version released in 2016), which is very actively being worked on and does work with even the latest JRE/Java version (OpenJDK 19 Early Access to this date).

Remove the call to matrixBuffer.flip()

To know why your code does not work requires you to know what Buffer.flip() (called via your FloatBuffer.flip()) does exactly:

Flips this buffer. The limit is set to the current position and then the position is set to zero. If the mark is defined then it is discarded.

(bold highlight by me).

You know, a NIO Buffer has a position, mark, limit and capacity. When you create a new NIO Buffer e.g. via BufferUtils.createFloatBuffer(size) then you will be given a FloatBuffer that is a view of an underlying direct ByteBuffer which has a capacity of size, a limit of size, a position of 0 and no mark set.

Usually, relative NIO Buffer put operations in the JDK will increment the buffer's position. However, JOML's Matrix/Vector.get(Buffer) won't do this, much like all LWJGL/OpenGL methods which take a NIO Buffer as parameter, such as GL15.glBufferData(...).

So, when you call Matrix4f.get(FloatBuffer) then the position of the supplied Buffer will not be modified and therefore, calling .flip() on that buffer afterwards will set the limit of the buffer to where the buffer's position was (likely 0).

The next thing you need to know is that LWJGL methods that take a NIO Buffer will use the buffer's .remaining() (which is .limit() - .position()) to determine the argument value to any size/length parameters for the underlying native OpenGL function call. In the case of glUniformMatrix4fv() with native signature:

void glUniformMatrix4fv(GLint location, GLsizei count, GLboolean transpose, const GLfloat *value);

LWJGL will infer the value for the count parameter based on the .remaining() / 16 of the supplied NIO Buffer. Since your Buffer likely has a .remaining() of 0 (due to the .flip() call when said buffer had a position of 0 - due to Matrix4f.get(FloatBuffer) not having incremented the position) the supplied OpenGL function argument will be 0, which will cause a noop in this case.

You are currently not including the runtime natives jar files of LWJGL into your fat jar file.

So, you don't need to add any JVM arguments like -Djava.library.path or -Dorg.lwjgl.librarypath but merely must make sure that the "natives-linux" dependencies/jar files are in the classpath when you run the jar.

One way to achieve this in your case is by not only iterating over the compile-time dependencies but over the runtime dependencies in your jar task to also collect those and add them to the fat jar file that you build, because you definitely will need them at runtime.

So, change this line:

You seem to be using a modularized Java application, that is, one that uses the Java 9+ module system with its module path and not the pre-Java-Module-System classpath.

So you are going to have to declare a dependency in your project's module-info.java as well, making it look something like:

The problem was that in the shader class, I was setting values too early, and the matrices multiplication can't work because of that. We just need to put

There's a bunch of problems in your code, and that's without even seeing the core of the problem yet, since it's in the // ... part:

• You don't use glfwSwapBuffers when you're trying to render in a headless setup, that's only needed when you render to the context back buffer and want to swap it to screen.

• You don't want both glGetTexImage and glReadPixels, they both read data from graphics memory to system memory. In your case you're reading the texture data in buffer then overwriting it with the backbuffer data, which should be empty since you never wrote to it.

• You definitely do not want glBlitFramebuffer, that's for copying from video memory to video memory. You seriously need to stop and read the documentation, throwing random functions at your video driver is a sure way to make it crash.

• You need to enable OpenGL's debug layer validation, especially while trying all these random functions. And related, you need to check your frame buffer setup (glCheckFramebufferStatusEXT), I'm willing to bet money you didn't, but you don't show your code.

• You don't show your frame buffer bindings, so I can't tell if you're doing this for sure or not, but you need to bind the frame buffer as "read" (GL_READ_FRAMEBUFFER) before reading from it. I only see a "draw" frame buffer binding, and you're only randomly clearing it.

• And lastly, you should never stall the CPU on a read operation from video memory, especially when you have things you should be doing, like video encoding. Use pixel buffer objects in a round-robin fashion to double or triple buffer the transfer, so there's no stall.

LWJGL 3 does not support on-heap (i.e. non-direct) NIO Buffers when talking to a native library like stb_image. Non-direct/on-heap NIO Buffers are those that are wrappers of a Java byte array.

With LWJGL 3 you always need to use off-heap (i.e. direct) NIO Buffers.

See https://docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html#direct for a further explanation of the differences.

So, instead of