LWJGL 2.2.1 Released

[broumbroum]

I don't use the Display class, because I've handled the Canvas by myself, some time before to impl. LWJGL.

As of LWJGL specs, mouse is handled within the Display class. if you want to get control of the mouse or keyboard, I could suggest this, taken from the Display source code I've just browsed :
set the system property org.lwjgl.opengl.Display.noinput to true before to call Display.create() org.lwjgl.opengl.Display.nomouse org.lwjgl.opengl.Display.nokeyboard seem available as well.
Please ask LWJGL creators if I'm correct.

[NateS]

run java -cp bin -Djava.library.path=libs\windows -Dorg.lwjgl.input.Mouse.allowNegativeMouseCoords=true org.lwjgl.test.input.MouseTest
push space to loose mouse grab.

Of course you are right. This is embarrassing, but I hadn't updated the JAR! It is working great.

[Mickelukas]

Support for negative mouse coords (if dragging outside), must set property: org.lwjgl.input.Mouse.allowNegativeMouseCoords

Awww, but if I do that in an applet I need to resign all of the files

yeah we discussed that - but if we fixed that with a public method we might as well add the other properties, and there wasn't time for that for this release.

Oh, I see potential for 2.2.2!

Mike

[Kai]

As usual, you guys really did a great job with LWJGL!

However, I think the EXT_direct_state_access implementation needs a refresh.
There are some methods that were included with OpenGL 3.0 in the original spec http://www.opengl.org/registry/specs/EXT/direct_state_access.txt that didn't find their way into the EXTDirectStateAccess class.

These methods are for example (copied from the spec):

        void *MapNamedBufferRangeEXT(uint buffer, intptr offset,
                                     sizeiptr length, bitfield access);
        void FlushMappedNamedBufferRangeEXT(uint buffer, intptr offset,
                                            sizeiptr length);

I make heavy use of the direct state access methods and I would really appreciate if at least these methods could be included (not yet with a new release but maybe in the svn trunk).

[spasi]

Thanks Kai, I'll check it out.

[spasi]

Hey Kai,

I have updated EXT_direct_state_access to the latest revision. I've also found a few problems with the postfix stripping we do on functions that work on NIO buffers, I think I fixed all of them (you may need to recompile your code if you used any of the weird ones that needed fixing).

As always, feel free to download a fresh build and let me know if you encounter any issues or if I've missed anything important.

[dronus]

Maybe a regression:

After updating to 2.2.1, my app often natively crashes with SIGSEGV  on 

    GL11.glTexImage2D(......, (ByteBuffer)null);

As GL specs states it is legal to give a null data pointer and fill the texture data later, for example with GL11.glTexSubImage2D.
This worked well for about one year, but now crashes, repeatable, occurs on at least two systems, but dependent on random circumstances it seems. Maybe the driver tries to set the texture to some memory location, see stack dump below.

Systems:
Linux 32-bit, ATI Radeon with proprietary drivers, Intel Core 2 Duo
Linux 32-bit, ATI Radeon with proprietary drivers, AMD Phenom X4

Top of stack:
C  [libc.so.6+0x78bb6]  memcpy+0x46
C  [fglrx_dri.so+0x2f0d00]
C  [liblwjgl.so+0x3a7a5]  Java_org_lwjgl_opengl_GL11_nglTexImage2D+0x65
j  org.lwjgl.opengl.GL11.nglTexImage2D(IIIIIIIILjava/nio/Buffer;IJ)V+0
j  org.lwjgl.opengl.GL11.glTexImage2D(IIIIIIIILjava/nio/ByteBuffer;)V+76
j  org.dronus.gl.Texture.<init>(IIIZ)V+204
...

any ideas?

[broumbroum]

you may add a zero-size buffer .

ByteBuffer b = ByteBuffer.allocate(0);

[dronus]

you may add a zero-size buffer .

EDIT: No, you can't. lwjgl expects the number of remaining bytes to match the image size.

Ok. So this was done by lwjgl in the past, but not anymore?

[spasi]

Nothing has changed from previous versions related to TexImage and passing null should work. You can try checking if there's any PIXEL_UNPACK_BUFFER bound or any other weird state that affects pixel unpacking. Sounds like a driver bug to me though. Does it happen on ATI cards and/or on Linux only?

Btw, I don't think null is allowed for TexSubImage, what would be the point? Null data is only useful when initializing the texture. Anyway, if you can find a way to reproduce this, please post it here and I'll look into it.

[dronus]

Btw, I don't think null is allowed for TexSubImage, what would be the point? Null data is only useful when initializing the texture.

Thats exactly my glTexImage2D call is for.

I have boiled down the error a little. Now I think lwjgl isn't to blame. The prerequisites are quite wild, so I just fix it by myself now :-)

Necessary circumstances so far:
-GL11.glTexImage2D is called with null for pixel data while GL11.glTexImage2D is compiled into a display list
-driver is ATI Radeon on linux

This scenario is quite rare and could be circumvented. So this was a false coincidence with your update I think, and ATI is to blame. Sorry for all that hassle.

[dronus]

Hello,

I now encountered an error on "lesser" devices, e.g. Linux WINE and old windows machines.

It seems that Display.create(..) depends on GL30 functions, which are not available on old devices

Exception in thread "main" java.lang.IllegalStateException: Function is not supported
	at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:64)
	at org.lwjgl.opengl.GL30.glGetStringi(GL30.java:517)
	at org.lwjgl.opengl.GLContext.getSupportedExtensions(GLContext.java:244)
	at org.lwjgl.opengl.ContextCapabilities.initAllStubs(ContextCapabilities.java:3442)
	at org.lwjgl.opengl.ContextCapabilities.<init>(ContextCapabilities.java:3690)
	at org.lwjgl.opengl.GLContext.useContext(GLContext.java:328)
	at org.lwjgl.opengl.Context.makeCurrent(Context.java:183)
	at org.lwjgl.opengl.Display.makeCurrent(Display.java:714)
	at org.lwjgl.opengl.Display.makeCurrentAndSetSwapInterval(Display.java:866)
	at org.lwjgl.opengl.Display.create(Display.java:844)
	at org.lwjgl.opengl.Display.create(Display.java:768)
	at org.lwjgl.opengl.Display.create(Display.java:749)

Not sure if I guess right..

Also I leaped from early lwjgl2.0 to this one, so not sure if it is a new problem.

Any idea ? 

[spasi]

This exception can only be thrown if the driver reports a GL version >= 3.0 but doesn't actually expose 3.0+ functionality (starting with glGetStringi). Sounds like a driver bug. You can try OpenGL Extensions Viewer to confirm it.

[Momoko_Fan]

It seems that Display.create(..) depends on GL30 functions, which are not available on old devices

If you're using an OpenGL wrapper, like GLIntercept or glslDevil, you will have issues with the LWJGL versions with 3.0 support. The driver says it supports 3.0, it goes through the wrapper and is reported to the application, but when any 3.0 calls are used, they are not defined in the wrapper library causing this issue.

[dronus]

This exception can only be thrown if the driver reports a GL version >= 3.0 but doesn't actually expose 3.0+ functionality (starting with glGetStringi). Sounds like a driver bug. You can try OpenGL Extensions Viewer to confirm it.

I've gone into the source and agree to that.  But this seems to apply to many environments so far: Wine, Debugging Wrappers, some 'normal' Windows 7 machines and Ubuntu 64 bit.  If I got hands on this machines again, I'll tell some details. WinXP, MacOSX and Linux32 seems fine so far.