Is it possible to access OpenGL ES from RoboVM wit

Question

Is it possible to access OpenGL ES on iOS from RoboVM without using LibGDX? If so, are there any useful references?

The only thing I can find is this super-simple demo from over 2 years ago:
      http://robovm.com/ios-opengles-in-java-on-robovm/
But it doesn't provide any functions besides glClearColor and glClear.

The Apple GLKit framework seems to be implemented, though. I just can't find all the actual glWhatever(...) functions...

Answer 1

Yes, it is possible. You need two things for this: 1. Access to the OpenGL ES functions (like glClear(...), etc.) and 2. a UIView in your app that can draw the GL image.

Turns out the second point is very easy. You can either use a GLKView (requires iOS 5.0) or a CAEAGLLayer (requires iOS 2.0) if you're feeling nostalgic. For both, there are tons of tutorials online on how to use them in Objective-C, which can readily be translated to RoboVM. So, I won't spend too much time on this point here.

Access to the OpenGL ES functions is a little more difficult, as RoboVM doesn't ship with the definitions file out of the box. So, we'll have to build our own using Bro. Turns out, once you wrap your head around how Bro handles C-strings, variable pointers, IntBuffers and such (which is actually quite beautiful!), it's really pretty straight forward. The super-simple demo I linked to in the original question is the right starting point.

In the interest of brevity, let me post here just a very abridged version of the file I wrote to illustrate the way the different data types can be handled:

import java.nio.Buffer;
import java.nio.IntBuffer;

import org.robovm.rt.bro.Bro;
import org.robovm.rt.bro.Struct;
import org.robovm.rt.bro.annotation.Bridge;
import org.robovm.rt.bro.annotation.Library;
import org.robovm.rt.bro.ptr.BytePtr;
import org.robovm.rt.bro.ptr.BytePtr.BytePtrPtr;
import org.robovm.rt.bro.ptr.IntPtr;

@Library("OpenGLES")
public class GLES20 {

    public static final int GL_DEPTH_BUFFER_BIT = 0x00000100;
    public static final int GL_STENCIL_BUFFER_BIT = 0x00000400;
    public static final int GL_COLOR_BUFFER_BIT = 0x00004000;
    public static final int GL_FALSE = 0;
    public static final int GL_TRUE = 1;

    private static final int MAX_INFO_LOG_LENGTH = 10*1024;

    private static final ThreadLocal<IntPtr> SINGLE_VALUE =
        new ThreadLocal<IntPtr>() {
            @Override
            protected IntPtr initialValue() {
                return Struct.allocate(IntPtr.class, 1);
            }
        };

    private static final ThreadLocal<BytePtr> INFO_LOG =
        new ThreadLocal<BytePtr>() {
            @Override
            protected BytePtr initialValue() {
                return Struct.allocate(BytePtr.class, MAX_INFO_LOG_LENGTH);
            }
        };

    static {
        Bro.bind(GLES20.class);
    }

    @Bridge
    public static native void glClearColor(float red, float green, float blue, float alpha);

    @Bridge
    public static native void glClear(int mask);

    @Bridge
    public static native void glGetIntegerv(int pname, IntPtr params);

    // DO NOT CALL THE NEXT METHOD WITH A pname THAT RETURNS MORE THAN ONE VALUE!!!
    public static int glGetIntegerv(int pname) {
        IntPtr params = SINGLE_VALUE.get();
        glGetIntegerv(pname, params);
        return params.get();
    }

    @Bridge
    private static native int glGetUniformLocation(int program, BytePtr name);

    public static int glGetUniformLocation(int program, String name) {
        return glGetUniformLocation(program, BytePtr.toBytePtrAsciiZ(name));
    }

    @Bridge
    public static native int glGenFramebuffers(int n, IntPtr framebuffers);

    public static int glGenFramebuffer() {
        IntPtr framebuffers = SINGLE_VALUE.get();
        glGenFramebuffers(1, framebuffers);
        return framebuffers.get();
    }

    @Bridge
    private static native void glShaderSource(int shader, int count, BytePtrPtr string, IntPtr length);

    public static void glShaderSource(int shader, String code) {
        glShaderSource(shader, 1, new BytePtrPtr().set(BytePtr.toBytePtrAsciiZ(code)), null);
    }

    @Bridge
    private static native void glGetShaderInfoLog(int shader, int maxLength, IntPtr length, BytePtr infoLog);

    public static String glGetShaderInfoLog(int shader) {
        BytePtr infoLog = INFO_LOG.get(); 
        glGetShaderInfoLog(shader, MAX_INFO_LOG_LENGTH, null, infoLog);
        return infoLog.toStringAsciiZ();
    }

    @Bridge
    public static native void glGetShaderPrecisionFormat(int shaderType, int precisionType, IntBuffer range, IntBuffer precision);

    @Bridge
    public static native void glTexImage2D(int target, int level, int internalformat, int width, int height, int border, int format, int type, IntBuffer data);

    @Bridge
    private static native void glVertexAttribPointer(int index, int size, int type, int normalized, int stride, Buffer pointer);

    public static void glVertexAttribPointer(int index, int size, int type, boolean normalized, int stride, Buffer pointer) {
        glVertexAttribPointer(index, size, type, normalized ? GL_TRUE : GL_FALSE, stride, pointer);
    }
}

Note how most methods are exposed via just trivial @Bridge-annotated native definitions, but for some it's convenient to define a wrapper method in Java that converts a String to a *char or unpacks a result from an IntPtr for example.

I didn't post my whole library file, since it is still very incomplete and it'll just make it harder to find the examples of how different parameter types are handled.

To save yourself some work, you can copy the GL constant definitions from libGDX's GL20.java. And the OpenGL ES docs are a great reference for the calling signature of the methods (the data types GLenum and GLbitfield correspond to a Java int).

You can then call the gl-methods statically by prepending GLES20. (just like on Android), e.g.:

GLES20.glClear(GLES20.GL_COLOR_BUFFER_BIT);

Turns out Bro is so smart that you don't even need to include the <framework>OpenGLES</framework> tag in robovm.xml any more, like you would with libGDX.

And - What do you know? - my app starts about 3 times as quickly as it did when it was still using libGDX. And it fixed another issue I had (see LibGDX displays black screen while app is paused but still visible (e.g. during in-app purchase password dialog) on iOS). "Yay!" for getting rid of unnecessary baggage.

The one thing that makes life a little annoying is that if you mess up the call signature of a method or the memory allocation, your app will simply crash with a very unhelpful "Terminated due to signal 11" message in the IDE-console that contains no information about where the app died.