Of course I was not going to make things easy for myself the same binary for the “engine” must work universally anywhere LWJGL will work (for now just Linux and windows – know anyone with a Mac?)….
As I understand it one of the main reasons for rewriting Java’s scripting engine from scratch was to take advantage of the invokedynamic byte code. This has had profound effects not in only in terms of execution speed but seemingly the rewrite has an effect on the integration between Java classes and scripts.
One thing right off the bat I though would cause issue is using buffers for things such as vertices, I was almost sure some madness like this would be needed
var intArray = java.lang.reflect.Array.newInstance(java.lang.Integer.TYPE, 7);
var vts = [ -0.5, 0.5, 0.0, 0,1, 0.5, 0.5, 0.0, 1,1, 0.5, -0.5, 0.0, 1,0, -0.5, -0.5, 0.0, 0,0 ] var BufferUtils = Java.type("org.lwjgl.BufferUtils") var verts = BufferUtils.createFloatBuffer(20) verts.put(vts); verts.flip(); GLES2.glBufferData(GLES2.GL_ARRAY_BUFFER, verts, GLES2.GL_STATIC_DRAW);
As you’re probably aware most of the “functions” in LWJGL are static methods so by creating a variable that’s a Java type of the class you can access those methods.
While you could just use the fully qualified class
var verts = org.lwjgl.BufferUtils.createFloatBuffer(20)
If you’re using other routines its probably easier to have a Java.type var kicking round
You can find a texture shader example here