LWJGL 3.2.2 released
Lightweight Java Gaming Library
GL4Java or LWJGL
GL4Java or LWJGL
GL4Java or LWJGL
June 11, 2003, 16:00:55 »
I previously made the statement that "GL4Java and LWJGL had identical performance". So why did I switch from GL4Java to LWJGL if the performace was identical you ask. Well, that's a GREAT question. Let me elaborate:
There were a few primary reasons for the switch:
1. Initialization: GL4Java initialized itself in the paint() method of Component. This means that until the window was realized, GL wasn't ready. Given that my application was single threaded, waiting for the UI thread to notify me of the initialization was a pain. Specificaly, it just made for ugly code. Ugly code = buggy code. It had to go.
2. Driving the renderer: GL4Java is inherently event driven as it sits in the paint() method of Component. For all of you newbies out there, given the examples that you see on the web, you may think nothing of this. EVERY example out there for OGL (with few exceptions) is driven from the UI thread. No game is driven off the UI thread. What is the first question that the newbie gone non-newbie asks? "How do I fix the frame rate?" or some derivative thereof. The bottom line is that the renderer is driven from the game (world) loop. Why are there no examples of this? Remember back to your school days -- this is a "starred" problem. You know, the ones that the professor gives extra credit for. It's "hard". I had to remove all of the UI driving points and force it to be loop driven. It did not like this.
3. Fails after "long" times: I test the app most of the time at 30fps. It drains less resources from the system since I'm always doing 1000 things. GL4Java would run for a long time (the time that I would test) without a problem. When I started to test at 60fps I would quickly notice that the application would slow to a crawl. My first reaction? FREAK OUT and start to pour over code. My second reaction? Breathe deeply and systematically test. When the game itself was run at 100fps without displaying it ran for days without a problem. (Yes people, you actually DO have to leave your application run for at least 10 hours to see if you have comulative effects before you ship it.) It had to be GL4Java. It seems that GL4Java did not like to be driven at high framerates for extended periods. It was eventually lose the handle to the window and you would get a frame every 5 - 10 SECONDS.
4. "Full screen": Full screen in GL4Java was never really full screen. It was an undecorated window that filled the viewport. Couple this with being UI driven and you had something that performed just as well fullscreen as it did windowed. This should not be correct as there is A LOT of overhead in windowed mode (the hardware has to copy from the 3D to the 2D part of the card, interact with the OS, etc, etc). So GL4Java and LWJGL had the same performance in windowed more, but when you switched to fullscreen GL4Java lost.
5. "Hello?!?": Where's the activity on GL4Java? The whole place felt like the business district of San Francisco on the weekends. Ever need to find a quick place to eat in downtown San Francisco after 5PM on a weekend? Well, the point is that you see tumble weeds rolling down the street cuz there ain't no one there (well, save the transients).
I hope that this is helpful to those trying to make a decision on which API to use.
(Someone PLEASE get rid of the blue background in the input boxes. I'm going BLIND.)
Re: GL4Java or LWJGL
Reply #1 on:
June 11, 2003, 16:21:00 »
You're right, GL4Java isn't as good as LWJGL...
But I've used the first for 6 months and GL4Java's got one thing more than LWJGL : it can be integrated into AWT or SWING. Ok, it just kills the performance, but, for example, making a level editor using GL4Java is much easier than if you were using LWJGL...
Anyway, I prefer LWJGL, except for one thing : using NIO package may improve performances, but it makes ugly code, and makes things a little bit complicated...
Chman (eh! I'm back
SMF © 2014