Jgles2pi thin Java wrapper of EGL and GLES

This is basically a stand in for documentation to the utils class of Jgles2pi a Raspberry PI port of Jgles2 a lightweight wrapper for GLES2.0 and EGL

Thanks to static imports like this

import static Jgles2.GLES2.*;

you can make GLES calls look like they are almost a part of the language for example

fragShader = glCreateShader(GL_FRAGMENT_SHADER);

however Java (thankfully!) isn’t C and there are some differences that for example dictate the need for direct memory buffers and besides convenience this is one of the reasons that there is a “util” class included with Jgles2pi. While there isn’t much in the way of documentation I’m making this post to help people get started with the util class – probably the best reference to the use of the util class is in the source test/Main.java

As the util class allows for keyboard input there are some key codes these are used simply by referencing them in your code for example

while(!util.keyDown(util.KEY_ESC)) {
    if (util.keyDown(util.KEY_Q)) xa =- ANG_SPEED * delta;
    if (util.keyDown(util.KEY_W)) xa =+ ANG_SPEED * delta;

There are a few things to discuss before we get to util.keyDown

void captureKeyboard();
void captureMouse();
void pumpEvents()

if you want keyboard or mouse events you must once call either or both of the capture routines, then in your main loop call pumpEvents() to update the state of the mouse and keyboard which can be interrogated with the following routines

boolean keyDown(int k);
int getMouseButtons();
int getMouseX();
int getMouseY();
void setMouseRelative(boolean rel);

Its not difficult by now to see that keyDown returns true whenever a particular key is pressed.  The state of the mouse buttons are returned as a bit pattern, normally the mouse X and Y coordinates are usually bound to the size of the screen, however you can switch to relative coordinates, which is simply a delta from the last time it was pumpEvents was called, which leads nicely onto…

int getWidth();
int getHeight();

Which returns the width and height of the screen returned by the broadcom routines, while creating a context via EGL you’ll need a handle to a native “window” this is supplied with the util function

int make_native_window();

currently GLES and EGL functions that require raw addresses for parameters have to be supported by using direct nio buffers there are some routines for creating these buffers

ByteBuffer createByteBuffer(int size)
IntBuffer createIntBuffer(int size)
FloatBuffer createFloatBuffer(int size)

in order to get an actual memory pointer to these buffers

int getByteBufferPtr(ByteBuffer buffer)
int getIntBufferPtr(IntBuffer buffer)
int getByteBufferPtr(ByteBuffer buffer)

it returns an int because of the 32bit platform… these routines are basically identical but are distinct only for parameter type convenience, given sufficient interest I could probably make parameter classes for all the GLES routines that require raw addresses but looking at the example you can see its far from impossible to use!

There are a couple pure java routines for convenience

public static int createShaderProgram(String name, String vertShaderText, String fragShaderText)
public String checkError()

createShaderProgram is simply a bit of boilerplate to return a GLES shader program handle, while checkError will call glGetError and will return an empty string unless there is a GLES error when it will return a textual representation of the error

you can grab the code here

Leave a Reply

Your email address will not be published. Required fields are marked *