LWJGL Threading problem

Yeah, you may be right…

They’re getting old, you know…

Heh, you think display list creation is something amazing when it comes to performance?

* darkprophet sighs

I give up, go do whatever you want to do…i dont care anymore. I’ll keep myself away from Xith from now on.

DP

you people are seriously boring.

I’d be surprised if there were any significant performance difference between LWJGL and JOGL. After all the fill-rate and geometry bottlenecks are the same so the negligible difference will just be down to the noise of context handling.

As for not likeing static APIs - OpenGL is a static API so we designed the LWJGL like that. It looks much nicer if you use Java 5’s static import feature to get rid of all the GL11 prefixes. Almost like C code. Something you can’t do in JOGL unfortunately.

Cas :slight_smile:

Did you know Java3D uses vertex-arrays under the hood? No VBOs yet.

It’s already hard to beat Java3D, we can only imagine how the next version of Java3D (beyond 1.5) is going to perform…

Well, OpenGL is not object oriented while Java is an oo language. So a lib designed for use with Java should be in an oo style. That’s why I don’t like LWJGL’s API.

It is for the GL constants in the GL class ;). For all the other methods it is not, you’re right. But I wouldn’t want to to.

Marvin

CPUs aren’t object oriented, therefore OO languages are generally incorrect.

Amazing logic huh? :slight_smile:

Well, I disagree. I also think that something like a non-static version of Math wouldn’t make much sense for the same reasons. And yea, I picked LWJGL because it was static.

CPUs are designed by humans, by your logic, logic isn’t OOP.

Demonstrative counter conclusion - it’s not my opinion.

You’re one year late on news.

Because you cared before?

Silly thread.

Cas :slight_smile: