FBO and GL2.0 support

Started by spasi, January 18, 2005, 21:04:55

Previous topic - Next topic

spasi

I just added EXT_framebuffer_object to LWJGL (bye-bye pbuffers!) and I had also completed OpenGL 2.0 support a couple of days ago. With this last addition, I think LWJGL is ready for version 1.0 as far as extensions are concerned.

Matzon, how about a news submition to opengl.org? :wink:

Matzon

well, we're planning on 0.95 this weekend - and since we're really fast on the trigger with FBO support (drivers don't even support it yet!), that release might be news worthy on opengl.org

Matzon


spasi

Thanks! :)

What's going on in cvs (the different Sys implementations) by the way?

elias

I'm mostly just cleaning up the code (and esp. the public beta) for 1.0. The SysImplementation thing made it possible to kill off a lot of native code, but there's no (intentional) functional change.

- elias

spasi

I was wondering about the System.currentTimeMillis() in DefaultSysImplementation (and the 1000 in getTimerResolution()). Won't there be a problem with this?

elias

No, on linux and mac the timer precision is ~1 ms. Besides, System.currentTimeMillis use gettimeofday internally at least on linux, just like we did, so there's no problem there. You could even improve it by calling System.nanoTime() or whatever it is if 1.5 is available.

Even newer (NT-based?) windowses has good precision, so I kept the win32 native code to get good precision on win9x.

EDIT: You may have been fooled by the apparent 100000 ticks/second precision of gettimeofday. In reality this is only in the ~1000 t/s range.

- elias

spasi

The timer on this windows machine reports a resolution of ~3 million t/s (actually, by successively calling getTime(), I can get a difference of 5 ticks and seems to be consistently going up when I add stuff in between). Isn't there anything else available on Linux & MacOS that has comparable accuracy? Sounds strange (unless the accuracy I get on win is highly artificial and actually is ~1ms like the others?).

Couldn't we use 5.0's nanoTime() if it's available? We could just detect the jre version and choose the implementation upon initialisation. It would probably have the same accuracy but better precision.

Anyway, if the accuracy is indeed ~1ms, doesn't this imply that consistent animations with >1000fps aren't possible?

elias

Well, there might be something better available, but the then current implementation was equivalent with System.currentTimeMillis() so that's why I simplified it and axed the native code. System.nanoTime support would be nice and could benefit all platforms.

- elias