Too damn tired to throw any comments right now.
/me is off to bed
missing DisplayOptions class in jogl, but as you said - you were tired 
k, so I can’t get jogl going, but I did notice that in lwjgl mode, you also render a cursor which (on my system) costs aroung 10% fps
J:489674
L:481593 -> 7zip -> 444580
;D
actually, JCD - when you awake, I would be very interrested in your comments about working with the jogl/lwjgl api…
Got 228fps for both of them. LWJGL one starts up a lot faster.
Specs:
Radeon 8500 / Dual 1GHz P3 / JRE1.5beta / Server VM / 640x480x32xwindowed / WinXP
(I turned off the Cursor in the LWJGL one, and it didn’t make even a single fps difference)
Cas 
What? Not even an executable jar? :-[
well, some more tests show that the cursor does not make any big impact - might just have been a fluke…
tried running both in fullscreen getting 620ish in jogl and 630ish in lwjgl…
Well sorry for not giving any more details, thing is, I was litteraly dead tired from staying up coding all night :sad panda:.
Here’s the displayOptions for anyone who cares; it’s a simple GUI for choosing screen mode.
Now here’s my $.02 on the whole situation;
JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.
I have few concerns however; The Display class is a bit bogus since it reports the existence of refresh rates that are ways higher than what my monitor supports.
In the TextureCubeMapL, where L stands for LWJGL, try scrapping line 215 where it says
if(rate > 85) //TEMPORARY FIX
continue;
and then try to go into fullscreen 32 bit, that’s right the jvm crashes…
A simple printout of the parameters array reveals refresh rates of order 120-100 which are definitely not supported @ 1024768, 800600 and 1240*1024.
Other things that I spent some decent time attempting to accomplish is cutting all ties with AWT/SWING; that means that I can’t use features such as BufferedImages and ImageIO, guess until some kind soul out there points me to some open source PNG/JPG loader, it’s pure TGA and BMP for me :sad panda:
Also it frustrates me how making a texture involves creating a Direct ByteBuffer; someone has no clue on how much time I wasted trying to get my TextureLoader to work with wrapped ByteBuffers…
But eventually I figured out and now everything runs fine.
/me goes to breakfast
[quote]JoGL does indeed run faster than LWJGL, in the range of ~10%
[/quote]
me = surpised ???
[quote] I have few concerns however; The Display class is a bit bogus since it reports the existence of refresh rates that are ways higher than what my monitor supports.
[/quote]
We just report what your display driver and monitor is telling us…
[quote] and then try to go into fullscreen 32 bit, that’s right the jvm crashes…
A simple printout of the parameters array reveals refresh rates of order 120-100 which are definitely not supported @ 1024768, 800600 and 1240*1024.
[/quote]
again, fullscreen works fine here (my monitor is fine at those values) - problem is that your drivers (in cooperation with your monitor) is claiming higher abilities than is possible.
We can’t magically remove modes, since we have no way of determening whether they’re valid or not. To make it even more fun, Linux typically returns 0 as refresh rate!
I am a bit puzzled by the JVM crash though?
[quote] JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.
[/quote]
I don’t get this statement…
you say that jogl is 10% faster? but you then say that, that is ok, since lwjgl brings other benefits to the table?
fwiw, I am almost not seeing any speed difference - in fact lwjgl is a bit quicker than jogl (negligible difference).
[quote] Other things that I spent some decent time attempting to accomplish is cutting all ties with AWT/SWING; that means that I can’t use features such as BufferedImages and ImageIO, guess until some kind soul out there points me to some open source PNG/JPG loader, it’s pure TGA and BMP for me :sad panda:
[/quote]
You don’t have to avoid ImageIO! - only if you want to natively compile.
[quote]Now here’s my $.02 on the whole situation;
JoGL does indeed run faster than LWJGL, in the range of ~10% though which is not that bad considering all the benefits that comes with switching to the latter.
[/quote]
I would love to see you summarize the benefits that you realized by using LWJGL. A table of pros and cons from someone who has actually used both to do the same thing would be great.
That’s bizarre, I know the same code executes to perfection when using
DisplayMode[] displayModes = GraphicsEnvironment.getLocalGraphicsEnvironment().
getDefaultScreenDevice().getDisplayModes();
provided with the AWT package, as in returning no more than 85Hz at 1024768, and 60Hz for 12801024.
I provided a case sample with the LWJGL version of texture cube mapping, can you please check it out?
I’m positive the JVM is crashing due to unsuppored resfresh rates fed to the monitor (120hz at 1024*768) though.
Back to benchmarking, it’s not a question about whetheir you think LWJGL runs faster than JoGL or not, as matter of fact the FPS numbers produced on my machine are definitely on JoGL’s side.
However you never know, it’s not like everyone out there has got the same machine.
But like I said I’d code using LWJGL anytime over JoGL for the simplicity and the non-AWT/SWING dependency.
Finally when I made the move towards LWJGL, I made this commitment of not using any AWT/SWING component, and I’m doing ok so far.
So any PNG loader out there by any chance?
[quote]You don’t have to avoid ImageIO! - only if you want to natively compile.
[/quote]
Or run on Mac
Hoping that one is fixed soon. I’ve noticed activity in CVS… maybe we finally have a Mac fix for AWT compatibility?
At this point I can’t draw a final conclusion on which one is better; JoGL or LWJGL.
But here’s few comments;
What I like about LWJGL is the fact that I can use a native compiler like JET and have Java-phobe run my demos without all the usual b*tching that comes with telling them to download a runtime.
It also loads a bit faster than JoGL and kicks almost immidiately at full speed rendering.
Another plus is, once GL is initialized after creating a window, you can call openGL functions pretty much everywhere without passing a valid GL instance to every single rendering function out there, and that alone is worth switching to LWJGL IMHO.
Now what bothers me about LWJGL is how they’ve created different instances of OpenGL matching the versions that were put up to the public.
It’s quite a hassle to look up GL15, 14,13,12,11 docs to figure what extension goes where, but I look at it as a history challenge (Never knew that CUBE_MAP was introduced as late as OpenGL 1.3)
Cutting the AWT/SWING ties however is a bit troublesome since you gotta look for a decent open source PNG/JPG loader on your own to still keep the comiling to native option, which is again why I’m using LWJGL…
Will think about more things later
IMHO Jogl is still way too unstable and buggy to be considered as a serious alternative. I’d estimate that about 50% of machines I’ve tried on that have a non-nVidia or non-ATi card fail to create a display surface. LWJGL display mode selection may be more lengthy code, but its a lot more robust (and actually fails gracefully too).
Syntax, speed, etc. differences are all moot if you can’t create a display surface in the first place.
ImageIO runs just fine on the Mac.
I think swpalmer means the LWJGL on mac problems of not being able to work with AWT without either locking up or getting no input.
- elias
Yes that’s exactly what I meant.
I’m having no luck with LWJGL at the moment, both demos compiled and ran on my computer and both gave a reading of 76fps which I assume is syncing to my refresh rate. However, when I ran the LWJGL version the culling (at least I think its that) seems to be messed up as you can see all surfaces of the Buda all the time, also (and I know this isn’t directly related to LWJGL) the display mode dialog if a bit iffy, if the mouse pointer leaves the window it disappears and I have to restart the app, and the movement speed of the mouse at the display options stage of the app is very slow.
Both these problems are none existent in the JOGL version, and obviously, the messed up display of the LWJGL is the main issue.
I think I probably need a better vid card ;D
Compiled with jogl 1.0beta, and lwjgl_unofficial_0_89 and j2sdk1.4.2_01 on winXPpro sp1, Geforce4Ti 4400 with Version 6.14.10.5303 drivers.