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! Enjoy!