No C++ game that Java cannot do (Chris Melissinos)

Aye. JOGL drags in megs and megs of dlls and classes. And it’s not a lovely API designed specifically with consoles in mind like LWJGL is :slight_smile: so ner ner ner.

Cas :slight_smile:

note to princecs programmer. Think there is some kind of loop in the LWJGL add function ;D

Same reason I think my own games are better than other peoples games, they are mine. That doesn’t mean it’s not true, but it definitely means that there is a strong bias there. I don’t use LWJGL, I’ve looked at the docs for it, but most of the time I’ve dedicated to LWJGL knowledge, has been reading princec posting about how awesome it is compared to jogl. I know both need some more work, off the top of my head I recall LWJGL doesn’t work on macs, and the fullscreen mode goes bonkers on my computer and a few others that I have access to.

Probably more important… what’s this pointer stab yourself in the head game, it isn’t the one you play with the var &var and *var controls is it?.

While I’m not saying that Cas isn’t completely LWJGL biased in this case it really is better. To have Jogl on a console you’d have to have a VM thats supports AWT fully (since Jogl requires an AWT window), however LWJGL will run on a simpler JVM (basically just Java language and JNI support).

This is also why it works more happily with JET (native java compiler thing).

This obviously doesn’t make LWJGL generically better than Jogl but it is technically a better fit in this case.

Kev

Yes, but as I said before, the only part of AWT that JOGL requires is just a device context which is no more or less than LWJGL requires. All the events and sound stuff in AWT is not needed (Jinput and JOAL take care of those).

[quote]Yes, but as I said before, the only part of AWT that JOGL requires is just a device context which is no more or less than LWJGL requires.
[/quote]
So you’re saying that you could replace the context JOGL gets from AWT with a native context, or an SWT context, and get the same results? That just isn’t true in JOGL’s current state. With some decoupling from AWT, perhaps. But right now you JOGL is tightly coupled with AWT and you cannot use it without pulling in AWT classes on the Java side - which requires the AWT shared lib for the particular platform. LWJGL is a much better candidate for consoles in this respect.