lwjgl 3 (yes 3!) a quick look

If all you’d ever done was look at the front page of LWJGL’s website you could (almost) be forgiven for thinking it was a dead project!  This is solely because over the last year or so they have been hard at work with the all new and shiny version 3.

While it’s out – its still early days really and I’m really waiting for the GLES bindings as I like to restrict myself to GLES 2.0 for the sake of easy porting (its everywhere now from embedded hardware to webGL) That said I decided to take it out for a quick spin, just to see how it was shaping up.

With it being such early days there is not much in the way of documentation, I did have to wrestle a little bit with making a build script that would compile and also run a small demo.

I decided to isolate and adapt the GLFW event demo and add the obligatory textured triangle to it…

For the sake of laziness speed I “borrowed” the demo’s IOUtils class – however it has been pointed out to me that this drags in the whole of AWT so you should use something else for loading an image into a bytebuffer.  There are a number of utility jars for this kicking around, you could even just stick to a very tiny PNG only one or take something that you can throw any image at and it will convert the data to your choice of GL data format – as ever with LWJGL the choice is yours.

I’ve targeted GL 1.0 and its evil calls to glVertex and glTexCoord2f, however I just wanted a tiny chunk of code to show it working with rather more than just a blank window.  When the GLES binding is in release, I’ll mess around with various buffers, shaders and so forth but that will obviously be a larger example.

The demo’s where all static code (nothing wrong with that) but I wanted to break all the event handling out of anonymous methods – as at a later date the event handling could be its own class (mainly just for the sake of manageability)  I don’t mind the odd single anonymous method, but I personally find great chunks of them make code less readable and sometimes harder to manage.

With the inclusion of GLFW3 the native window handling code is all abstracted away in a nice simple cross platform way, I often think that EGL didn’t quite go far enough but there are good reasons for stopping where they did…

I do like the way the demo’s use static imports as now (for example) GL10.glColor becomes just glColor and you could be looking at C code as easily as Java, its a small thing but its less typing and more readable which I’m all for.

One thing that did have me almost tearing what hair I have out, was the infamous library path! I could only get it working with an absolute path, and for the sake of a distributed launcher script it would have been nice to be able to get it to work relative.

  <jvmarg value="-Dorg.lwjgl.librarypath=${basedir}/native" />
  <jvmarg value="-Dorg.lwjgl.librarypath=native" />

seemed to do the trick, notice ${basedir} this gives you ant’s working directory (the one ant was run from)

I’m not sure what’s the best solution just yet for an end user (of your product), in a Linux script you can always back tick pwd but not being a windows user I wouldn’t have a clue about doing that from a bat file…

Looks like this is was a bug that was fixed hours after I did my pull from git! relative paths do work with library path.

I’ve included the quick and dirty project with this article, you’ll need to make and populate a jar folder and a native folder – I’ll leave that as an exercise for the reader.

One thing I did notice was that with everything included (all binaries and cross platform native libs) a compressed archive was only a little over 3mb (thankfully) no bloat there then!


Leave a Reply

Your email address will not be published.