Any Last Requests?

[lamster]

Any reason you don't expose the GLU tesselation routines?  They're awfully handy to me and are exposed cleanly in jogl thru a callback class.  Am I just missing them in LWJGL or are they not here?

I'd like to see tesselating exposed in 0.9; otherwise, would you please explain why you've left it out?

[elias]

They were initially left out because of the ugly hacks needed to callback java from C. However, erikd has implemented most of GLU in pure java for 0.9 instead.

- elias

[spasi]

GL.glSupport15(true);
GL.glFinish();

:wink:

[elias]

:-)

GL_ARB_multisample support is also in for linux and win32.

- elias

[princec]

Buffer checks 95% complete too. There are just a few that I don't know what to do with at the moment.

Cas

[cfmdobbie]

A while back there was some push towards removing unnecessary extensions to methods.  Is that still the intention, or are the type qualifiers now deemed a necessary evil?

There are still a load of these extensions littered over the place - just scanning through CoreGL11 there is glLoadMatrixf, glLightModeli, glLighti, glPixelStoref, glPixelTransferf, glNormal3b, glScalef, glRotatef...

[elias]

Well, we're deliberately not removing the ones that don't have a Buffer to match its type with. Those seem to cover all your mentioned functions except glLoadMatrixf which seems to be all right even so:

       public static void glLoadMatrix(FloatBuffer m) {
               BufferChecks.checkBuffer(m);
               nglLoadMatrixf(m, m.position());
       }
       private static native void nglLoadMatrixf(FloatBuffer m, int m_offset);

(the f version is private)

- elias

[cfmdobbie]

Just out of interest, why do you remove the suffixes from methods that are distinguished by Buffer type, but not from methods that are distinguished by primitive type?  Is it just policy, or are you trying to limit the number of automatic widening conversions?

Re: glLoadMatrix, I guess that's already been fixed since last release!  I dunno, fixing things before you're asked... What kind of Open Source project is this?

[elias]

:-D

Just wait for 0.9, it will definitely please most of you.

Yes, we try to avoid widening conversions by keeping those postfixes.

- elias

[cfmdobbie]

Additional methods in Window to allow setting the size and location of already-created windows would be useful.  I know you generally don't like windowed mode, but as people are using it it might be worth adding these methods.

Also useful for Xith3D's CanvasPeer:

http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1077533097;start=0#0

[princec]

Yes, we'll add methods to reshape windows in windowed mode, with a clear explanation of why they might have no effect

Cas

[spasi]

I just finished render-to-texture. It works fine (I tested it in Marathon - gave me a 20-30% speed increase :wink: ), but I don't like the way I did it, api-wise. render-to-texture is win32 only, render to depth texture and render to rectangle texture are NV only, so trying to make it system-independent was quite difficult.

I'd like to hear any opinions on the implementation (if anyone has time to check it out) :roll:

[elias]

Well, I don't like the WGL* references obviously. However, because render-to-texture is only supported in win32 (no extension exist for linux and probably not for mac either), we could keep it like it is now, _but_ make it clear that the API will change (and functionality might be cut out) when the GLX/AGL versions are out, even after LWJGL 1.0.

- elias

[princec]

Another argument for splitting LWJGL functionality up by core and extensions. We should keep the cross-platform cross-vendor stuff in the core and then move out nvidia specific code into lwjgl-nvidia and so on.

Can render-to-texture's public API be made to look implementation agnostic? <edit> Actually it seems like the public API is already implementation agnostic. We need to be able to query for RenderTexture caps in GLContext though in a platform independent manner.

Cas

[spasi]

Actually it seems like the public API is already implementation agnostic.

Yes, it is. Anything that has to do with WGL is hidden. You just query the pbuffer capabilities and pass a RenderTexture if supported. I just had to create some tokens to hide the WGL ones (one of the stuff I don't like the way it is now).

We need to be able to query for RenderTexture caps in GLContext though in a platform independent manner.

I think we should keep the query in pbuffer, as they are so closely related. It'll have to clean-up somehow though, maybe later as elias said.