Few days ago I have decided to port the IDE from JOGL(Java Binding for the OpenGL API) to LWJGL (Lightweight Java Game Library 3). Surprisingly it went smoother that expected after ~5 hours I had the graphics part ported, for the input I have decided to write my own wrapper which took few hours.
I have used JOGL and LWJGL before I even started working on the IDE, when I started to work on the IDE (well actually a project that the IDE is based on) I have decided to go with JOGL as LWJGL2 didn’t support multiple windows. Now that LWJGL3 is here and support multiple windows there was no need for me to stick with JOGL.
There were few reason why I wanted to port the IDE to it, but I will go into details later on. First I want to say that technically there was no need to port it. Everything was working fine, except for random crashes and by random I mean really random, I was able to replicate the crash ~70% of the time but where and why it was happening was a mystery. The crash was actually my fault, but because it was showing as a native stack error (accessing memory) originating in java executable I was not able to figure out what was causing it.
When I started to port the IDE to LWJGL I didn’t know if this will fix the crash or at least let me know more less what is causing it. Well that’s not exactly true I knew that this kind of error could only be caused by an external lib and JOGL was the only one and I also knew that LWJGL has proper log when it crashes, so there was a good chance it will work/help.
After porting the IDE and crashing a few times I have checked the log files and the cause of it was in my Model Viewer rendering code and FlexibleRenderer (my wrapper for Vertex Arrays, really flexible for prototyping and ultra fast and easy to use when extended). It was caused by me forgetting to disable few OpenGL states (or removing few lines of code too much when cleaning up).
Should I go back now?
Well at this stage I could easily just go back to JOGL and remove crash, but I had all of the graphics calls ported and to get it to fully work I just needed to fix few minor things and make the input wrapper. I thought I might test it, I have been using LWJGL a lot in the past, modding MC and writing a game, the usual thing I do first is benchmark.
The results really surprised me, almost empty screen rendered with 6000fps, almost double (compared to 3500fps) and more advanced ones like Model Viewer and File Viewer gained ~20-30%, which for a “simple” change is a lot.
More reasons why I decided to go with LWJGL
Static OpenGL calls, in JOGL passing the GL container around to every single functions is really annoying.
OpenGL versioning, with LWJGL I have to know which version of OpenGL the call is coming from, while most people would find this annoying I really like this approach as I know exactly which calls I would need to replace to lower the required version of OpenGL and I can stay away from 4.0+ calls.
BufferUtils, an extremely useful class, it provides a quick way to create buffers that will be compatible with OpenGL, not sure if JOGL has one as well but I haven’t seen it used anywhere.
GLFW is now the window library included with LWJGL, it is low level, single threaded (with input polling) and fast, JOGL can use AWT, SWT and Swing each of those has their own problems and they are really old.
Recording, I’m using Open Broadcaster Software (OBS) to record (yes, it can also record) and with JOGL it just didn’t work, I had to use DxTory to pass in the DirectShow Output and record it like this. I could use just DxTory but I prefer OBS for some reason. With LWJGL OBS has no problems recording using the Game Capture mode, that saves a bit of time while setting up.
Don’t get me wrong I’m not saying you should use LWJGL, it really comes to what you need and which one you like more. JOGL is a great library, it has advantages especially for beginners and in some cases it is easier to use, but for me LWJGL has everything I need and the way the code is written using it appeals more to me. Again this is my personal opinion and not something you should take as a fact, if you are trying to decide which one to go with, get both and compare, that’s the only way.