LWJGL with OpenGL ES 2

[spasi]

Btw, I've made the branch (/branches/opengles), will start committing in there, probably tomorrow.

[frostybeard]

OK, LWJGL is in the Ubuntu repository in the armel port, but I will have to build your new ES version. Then I can test it.

Hopefully I can figure out how to build it in Ubuntu 11.04 in a reasonable amount of time. I am just upgrading from 10.10 to 11.04. Then I need to run the tests to see if OpenGL ES2 and so forth works in 11.04, and if not, get the needed packages. I am hoping to get a Trim Slice computer soon, then the Tegra testing can be done.

I've been trying to build it in my x86_64 Fedora box, but my JRE is the wrong version, or I am missing some other detail. It just spews out hundreds of errors when I run ant. I've been busy too, but nothing like the Amazon cloud disaster.

[Matzon]

I dont think he has comitted it yet 

he just created a branch containing trunk

[frostybeard]

It will probably take me a few days to get Ubuntu upgraded and graphics accel. working.

Compiling the natives on an arm target will be the challenge. I've been trying to compile the latest stable branch in Fedora.
I haven't had much success, and I couldn't find much documentation on how to compile a Linux target.

There is some of Spasi's code in there already in the /branches directory.

[spasi]

I got the windows build to run on Sunday, the linux one yesterday and I also added support for a bunch of non-NV extensions. I'll do a bit of clean-up and commit this afternoon. That branch doesn't have anything ES related yet.

[spasi]

Everything has been committed now, feel free to checkout the branch and do some tests. Details:

- OpenGL ES 2.0 support only, there's nothing for 1.x.
- No Mac support, AWT integration and Pbuffer not supported.
- All extensions are supported, except old ones that targeted ES 1.x (fixed-function and fixed-point data stuff).
- Simple API; everything like normal LWJGL, except you use a new package (org.lwjgl.opengles). There are new PixelFormat, ContextAttribs, GLContext and ContextCapabilities classes in there. Display is still in org.lwjgl.opengl and there are new methods to create GLES contexts. For example:

Display.createES();
Display.create(new org.lwjgl.opengles.PixelFormat());

There are a few new ANT targets for ES:

- generate-opengles
- generate-opengles-debug
- generate-opengles-capabilities
- compile_native_es
- jars_es

To build on a clean checkout, run the following:

- ant generate-all
- ant compile_native_es

I have included an OpenGL ES emulator in libs. It's PVRVFrame from Imagination Technologies, it's the most functional one in my experience. To run with the ES build on desktop, you need to add the emulator to the execution path.

- On Windows:

SET PATH=%PATH%;.\libs\windows (run this once)
java -cp bin -Djava.library.path=libs/windows org.lwjgl.test.opengles.Gears

- On Linux:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libs/linux (run this once)
java -cp bin -Djava.library.path=libs/linux org.lwjgl.test.opengles.Gears

As you can see I have ported some of our tests to OpenGL ES. The org.lwjgl.test.opengles.util package contains a bunch of utility classes that will get you quickly started with ES2.0. Since there's no fixed-functionality present, you're going to have to use shaders, VBOs, etc. The GLMatrix class is particularly interesting because it simulates the fixed-function OpenGL matrix stack, you simply import it statically and you can use stuff like glLoadMatrix, glTranslatef, etc, then you do a glGetMatrix to get the current matrix to upload to your shader uniform. See the Gears demo source code for details.

Enjoy and let me know if you encounter any issues.

[spasi]

Btw, if you seriously plan to use this on an ARM device, you will probably have to do a few changes to the current source code. First is removing anything AWT related. Even if the VM you run on supports AWT, you really want to avoid touching AWT, it's too much memory bloat for mobile devices. Second is changing LWJGL to assume 32-bit pointers (also avoid anything long/double related). This requires more changes, but it's doable.

[frostybeard]

Btw, if you seriously plan to use this on an ARM device, you will probably have to do a few changes to the current source code. First is removing anything AWT related. Even if the VM you run on supports AWT, you really want to avoid touching AWT, it's too much memory bloat for mobile devices. Second is changing LWJGL to assume 32-bit pointers (also avoid anything long/double related). This requires more changes, but it's doable.

OK I will get on that as soon as I can. I can check it on OMAP4 (Panda board) in Ubuntu Maverick and possibly OMAP3 and Freescale i.MX515.

[spasi]

Hey frostybeard, any news?

Has anyone else tried building and testing the ES branch?

[Sordul]

I actually having problems to build it but that's more because of my lack of c++ / eclipse wisdom (native libraries). However, OpenGL ES integration is a great thing. I would be happy to see this beeing merged into the trunk some day!