CODEWITHSUNDEEP
javaopengl-esswigjogl
seahorse
seahorse

Reputation: 2470

SWIG based Java interface for OpenGL ES 2.0 and EGL for SWT

I was planning to interface the native API exposed by OpenGL ES 2.0 using SWIG.

I know there is JOGL, but somehow it has too many abstractions, classes and code.

All I want is a very bare minimum and simple Java API to interface with OpenGL ES 2.0 and EGL application. Finally my app will use SWT. SWIG can be used to generate the Java interface using the C API exposed by OpenGL ES 2.0 and EGL.

With regards to EGL I simply have to extract the currentwindow handle of the java window and pass on to EGL, would this work?

Has someone already tried this out or it isnt as simple as it seems(and that is the reason we have to use JOGL)?

Upvotes: 0

Views: 493

Answers (1)

Flexo - Save the data dump
Flexo - Save the data dump

Reputation: 88751

JOGL in its basic form is pretty much just a thin wrapper over the OpenGL interface.

Where things get more complicated in that wrapper is when you start looking at buffers. In the C OpenGL interface that's all handled by void*. In Java that doesn't make sense at all - the closest Java has is Object, but that can't be used in this way.

... too many abstractions, classes and code.

In C where we say "just take this chunk of memory and use it as an interleaved list of vertices, normals and colours" we need extra support on the Java interface to allow us to get something like that into memory flexibly and efficiently. This I suspect is the root of your observation about the large numbers of abstractions, classes and code.

In OpenGL 3.0 with JOGL you can directly and simply use the deprecated fixed functionality immediate mode, e.g.:

gl.glBegin(GL2.GL_QUADS);          
    gl.glColor3f(0.0f, 1.0f, 1.0f);   // set the color of the quad
    gl.glVertex3f(-1.0f, 1.0f, 0.0f);      // Top Left
    gl.glVertex3f( 1.0f, 1.0f, 0.0f);       // Top Right
    gl.glVertex3f( 1.0f,-1.0f, 0.0f);      // Bottom Right
    gl.glVertex3f(-1.0f,-1.0f, 0.0f);     // Bottom Left
gl.glEnd();

In OpenGL ES that fixed functionality immediate mode rendering stuff just doesn't exist, because it's horrendously inefficient on the types of devices that OpenGL ES runs on. As a result all the functions you're left with in JOGL's bindings to OpenGL ES are the ones that need complex abstractions in Java to be able to use, because they rely heavily on the void* pointers to buffers that are hard to expose meaningfully within Java.

Long story short - if you write your own Java OpenGL ES wrapper it will be no simpler than the JOGL one. JOGL is the simple OpenGL wrapper for Java.

Upvotes: 1

Related Questions