Any Last Requests?

[elias]

... and the native cursor (if any) is reset at Mouse.destroy() too as you requested. Must be your birthday or something, eh dobbie?

- elias

[cfmdobbie]

:mrgreen:

It is a good day to be an LWJGL user indeed!

[spasi]

OK, we'd like some opinions on a problem that occured.

1.5's static import can't be used with inherited static fields and methods. This affects some of the LWJGL classes (e.g. ARBVertexProgram & ARBFragmentProgram that extend the private ARBProgram). We wouldn't like to duplicate code to solve this. So, any suggestions?

I'd prefer making the base class public, although it may complicate the documentation and confuse people.

[princec]

I don't see a problem with making it public. So long as it's abstract it won't confuse anyone I don't think.

Cas

[cfmdobbie]

Well, ARBProgram involves quite a lot of code - it's not at all sensible to duplicate all that (unless you use a preprocessor to insert it into the appropiate files - yuk).  Given the choice between duplicating it or making it public, I'd vote for making it public - although not knowing anything about using these classes I really don't know how confusing it's going to be.  From the API it looks like you may end up pretty much alternating calls if you use ARBVertexProgram... which would suck.  Are there any other solutions?

I think more's the question why can't static import be used in this way?  Is it a bug or is there a good reason for this?  Seems a bit fishy to me.

[cfmdobbie]

• Lose the postfix on GL11.glLightfv(int, int, FloatBuffer), GL11.glLightiv(int, int, IntBuffer) and GL11.glMultMatrixf(FloatBuffer).
  
• GL15.glGetQueryObjecti(int, int, IntBuffer) and glGetQueryObjectui(int, int, IntBuffer) - you could remove the i postfix, just leaving the u on the unsigned method, if you wish.
  
• Wrong CRLF format in ARBFragmentProgram.java, NVFragmentProgram.java and NVProgram.java.

[spasi]

Given the choice between duplicating it or making it public, I'd vote for making it public - although not knowing anything about using these classes I really don't know how confusing it's going to be.  From the API it looks like you may end up pretty much alternating calls if you use ARBVertexProgram... which would suck.  Are there any other solutions?

Well, I've used them a lot and and it seems like 3 things already, not 2. There's the program handling and then there's VPs and FPs. They've done the same thing themselves with GLSL. There are shader objects and then there's vertex and pixel shaders. It makes sense to make it public, but an "ARB_program" extension doesn't exist, so we should document this well for newbies.

I think more's the question why can't static import be used in this way?  Is it a bug or is there a good reason for this?  Seems a bit fishy to me.

That was my first thought too. Even IDEA doesn't complain when I try it. I read the spec and couldn't find anything that forbids it. Anything visible should be imported.

Anyway, this will also affect NV_VP+NV_FP and VBO+PBO(coming soon).

[elias]

cfmdobbie: Thnx, it should be fixed now.

[princec]

I think you'll find that the class itself is not visible, and that's the problem - you simply can't reference it as it's not in scope.

Cas

[spasi]

New in CVS:

ARBProgram and NVProgram are now public and final. The corresponding common vertex_program and fragment_program functionality can be found there. The same applies for ARBBufferObject. It contains the common functionality of ARB_vertex_buffer_object and the new EXT_pixel_buffer_object.

New extensions:

EXT_Cg_shader
EXT_depth_bounds_test
EXT_pixel_buffer_object
GL_NV_fragment_program_option
GL_NV_vertex_program2_option

[cfmdobbie]

BufferChecks.java:67

static void checkBuffer(Buffer buf, int size) {
		if (buf.remaining() < size) {
			throw new BufferOverflowException();
		}
	}

Request: Include buf.remaining() and size in the exception message.  I had to dig through the LWJGL source to find out that it wanted a 16 element buffer.

[elias]

Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?

- elias

[cfmdobbie]

Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?

Hmm.  Even if the heirarchy isn't accessible via static import, it's probably handy to keep it in place so the normal ARBFragmentProgram.GL_CURRENT_MATRIX_ARB method of access still works for those that don't use static import.

The static import problem still sounds like a bug to me... :-/

[spasi]

Spasi: what is the reasoning behind not letting classes extend each other anymore? E.g. not letting NVFragmentProgram extend NVProgram?

Because I got too excited with static import! Now most of our GL statements are actually ONE line! :wink:

Well, seriously, for two reasons:

A) Using static import is THE way to use LWJGL. We don't want new people to watch ugly code, right :wink:? This way, we kinda force users to do it.
B) Normally, one would create wrapper classes for things like programs and buffer objects. Allowing access to the management code from both (e.g.) VertexProgram and FragmentProgram, one may assume there are two managements, thus duplicating code in their wrappers. Again, we're forcing them to read the (not really clear) specs better and thus, understand what they're doing better.

If anyone has a big problem with that, I don't mind doing the hierarchy again. It just felt more natural this way for me.

[cfmdobbie]

Will LWJGL 0.9 require a 1.5 JVM, then?