I mean no malice. I figued that I should present the opposing view to Cas' statements so that we understand the implications of the "pros" (i.e. a "pro" can actually be a "con").
1. Using statics (which I'm not against in the GL layer BTW) allows any class to insert GL calls onto the stack at any point. You cannot prevent an arbitrary class from calling into GL. This throws "defensive coding" out the window.
Boo hoo! to all of those that can't pass a simple reference around! That "annoyance" provides you with the knowledge of exactly what classes can access GL. This simplifies debugging and maintenance.
Think of it like the American HIPPA standing (it's a medical privacy law). HIPPA doesn't care about "who accessed the data", it cares about "who had the ability
to access the data". The difference is subtle but very important.
2. Threads are not bad. We all need to get out of this mindset. Just because most people seriously fubar threads does not mean that we should eradicate them. Since I don't want to waste space I will refer you to:http://www.realityinteractive.com/software/sc/background/benefits.html
where you can get a taste of why you want threads. (No, this isn't a product plug.)
3. Removing the ability for a developer to make a simple (read: less error prone) call to set or retrieve a GL value via an array is just bad mojo. See the example below:
final int textureIdentifier = new int;
final ByteBuffer buffer = ByteBuffer.allocateDirect(4 );
buffer.order(ByteOrder.nativeOrder()); final IntBuffer textureIdentifier = buffer.asIntBuffer();
final int textureId = textureIdentifier.get();
Don't forget to call rewind()
between retrievals of the value from textureIdentifier
. Oh! And be prepared for cryptic VM crashes and core dumps.
I should point out that glGenTextures
is even worse than I'm making it out to be: there's no number
parameter. After scouring the code (as this function has no javadoc) I determined that:
nglGenTextures(textures.remaining(), textures, textures.position())
This means that if I wish to use a shared buffer of size n
when I only want m
textures, I need to explicitly set the position and limit of the buffer before I can make the call, so add two more calls to the already bloated code.
The bottom line is that more lines of code = larger possibility for bugs. The second bottom line is that you're making the trade-reability-for-performance decision for me. The developer should be provided with the ability to make that decision.
4. "GLCaps"? "GLCapabilities" too long to type?
Seriously now folks, why doesn't the library protect me from making a call to an unavailable extension? More code = more bugs.
5. The debugging is done in a separate dll? Oye! The developer does not have the ability to choose at runtime nor selectively choose which set of GL functions they want debugged. Why isn't this done in the Java layer where more control can be handed to the developer?
Now with all of this said, I stand behind the LWJGL effort 100% and I recommend it to everyone that I talk to. Those guys are doing a great job. They're handing bug reports very quickly. There are no production bugs that I have ever run into that have ever stopped me from coding.
If you're going to write a standalone game, use LWJGL.