Any Last Requests?

[cfmdobbie]

Question: Should org.lwjgl.opengl.glu.Quadric be made abstract?  Looking through the code I can't see any reason for a user to directly create a new Quadric object, only a subclasses of it.

[elias]

No LWJGL should not require a 1.5 JVM. So yeah, I think I like the hierarchy back. I think it is important to call all the (say) VertexBufferObject functions from the same class, not caring whether some functionality is shared with PBO.

- elias

[spasi]

Of course it'll not require 1.5. You can still say ARBProgram.glBindProgram(ARBVertexProgram.GL_VERTEX_PROGRAM, x); if you want to. No problem there. Anyway, I'll put the hierarchy back, when I return home.

[WiESi]

Yeahh! Only one week till easter!

WiESi

[tomb]

Is it possible to add a function that resizes a fullscreen window, without destroying the gl context? What I want is to change resolution from inside the game without loosing the textures and the gl state.

I know this is a bit late for the 0.9 release, but maybe for the 1.0?

Any comments?

[spasi]

The GLSL update changes are added in cvs.

Could someone send me fresh win32 & linux builds?

[princec]

I'll send you a Win32 build; Elias can most likely send you a Linux build.

tomb - we're about to change the whole Display / Window API so that Window will no longer be used. It's all going in Display, and it's going to be quite bean-like in that you should simply be able to tweak properties all day long and it Just Works.

Cas

[elias]

http://odense.kollegienet.dk/~naur/lwjgl-linux-20040627.zip

(although you haven't comitted any native changes lately, but that might be deliberate)

- elias

[spasi]

Thank you guys.

No native changes from me, but many by others. I just didn't have any latest binaries (especially for linux).  :wink:

[cfmdobbie]

Just a quick thought to throw at you:

While you're making the context-handling functions more user-friendly, is it possible to do the same w.r.t. extensions that make it into the core unaltered?  i.e. can you clean up code like the following:

if(GLContext.OpenGL13)
  GL13.method();
else if(GLContext.TheExtension)
  TheExtension.methodEXT();
else
  throw new Exception("Doh");

Are there many situations in which the library can guarantee the code would have worked the same, if only the developer had added a load of version-checking boilerplate instead of calling the core method directly?

[elias]

Apart from the implementation burden on us, there is the subtle problem that the original extension spec often is slightly different from the core spec of the extension. And as such, we can't guarantee the same behaviour just by re-routing the method call.

- elias

[cfmdobbie]

Righto, so the answer is "not enough to make it worthwhile"!

I can live with that, it was just an idle thought.

[elias]

I wouldn't say it isn't worthwhile. The spec differences are mostly clarifications, so it isn't entirely impractical, we just need to document the fact properly (maybe with an explicit runtime flag).

I guess that for a particular extension, if the core version is available, the original extension is also available.

- elias

[Orangy Tang]

Small suggestion - do a check of the 'size' arg to glVertexPointer (which according to my docs should always be 2, 3 or 4). Going by Eclipse's intellisense/function tooltips it suggests that the 'size' param is the size of the buffer you're binding, rather than the size of the coords it contains (and hence me typing in a whacking great number :oops: ).

Probably only want it enabled in debug mode though.

[cfmdobbie]

Would changing that argument from "size" to "vertexSize" fix things for you?  Eclipse should generate its popups directly from the source and javadoc, so that might help to make it less confusing.