This is just a small bugfix release, however it includes 2.2 which never got announced (busy as hell, scrambled to build it before moving!)
2.2.1
- FIX: Mouse Grab should now work on Windows when using Display.setParent()
2.2.0
- Support for OpenGL 3.1 and 3.2
- Support for the following extensions: NV_shader_buffer_load, NV_vertex_buffer_unified_memory, GREMEDY_string_marker, AMD_draw_buffers_blend, ARB_depth_clamp, ARB_draw_buffers_blend, ARB_draw_elements_base_vertex, ARB_fragment_coord_conventions, ARB_provoking_vertex, ARB_sample_shading, ARB_seamless_cube_map, ARB_shader_texture_lod, ARB_texture_cube_map_array, ARB_texture_gather, ARB_texture_multisample, ARB_texture_query_lod, ARB_vertex_array_bgra, EXT_separate_shader_objects, EXT_texture_snorm, NV_copy_image, NV_parameter_buffer_object2, NV_texture_barrier
- Support for GLU tessellation (using JOGLs implementation -
possibly missing license file - will update for next release license in repo) - Added support for PIXEL_STORE state tracking.
- Changed PBO GLChecks to use LWJGL's state tracking instead of using glGetInteger.
- Support for alpha blended icons on win32
- Misc improvements to applet downloader to handle download errors
- Added Mouse.isInsideWindow()
- Support for tracking mouse outside window on drag
- Support for negative mouse coords (if dragging outside), must set property: org.lwjgl.input.Mouse.allowNegativeMouseCoords
- Latest jinput
- Fix for ALC11 functions not working
- Fixes for 64bit windows (should work better now)
https://sourceforge.net/projects/java-game-lib/files/Official%20Releases/LWJGL%202.2.1/
Remember to donate (http://lwjgl.org/donations.php) ;)
got to try tesselation, thx a lot for this release ! ;D
One tiny notice : openal.dylib -> rename to libopenal.dylib .
EDIT : GLUtesselator is great !! Thx
How does tracking the mouse outside window on drag work? I have a Swing app that has a panel that renders using LWJGL. Mouse interaction has always been awkward because mouse movements aren't captured outside of the LWJGL window. I tried setting the System property, dragging, and not dragging but I didn't see a difference from the old behavior.
Quote from: NateS on November 15, 2009, 22:47:18
How does tracking the mouse outside window on drag work? I have a Swing app that has a panel that renders using LWJGL. Mouse interaction has always been awkward because mouse movements aren't captured outside of the LWJGL window. I tried setting the System property, dragging, and not dragging but I didn't see a difference from the old behavior.
Which OS are you on?
Quote from: javalwjgl on November 15, 2009, 22:51:25
Which OS are you on?
Windows 7.
After suffering all this time I just came up with a solution! This is working:
Point mouseLocation = MouseInfo.getPointerInfo().getLocation();
SwingUtilities.convertPointFromScreen(mouseLocation, canvasContainer);I just do the delta myself.
Doesn't handle the mouse going up outside the app though. :( I need the mouse up if the user mouses down then drags out of the LWJGL window and mouses up. Swing does this. I'd be content with a workaround that uses Swing.
Quote from: NateS on November 15, 2009, 22:47:18
How does tracking the mouse outside window on drag work? I have a Swing app that has a panel that renders using LWJGL. Mouse interaction has always been awkward because mouse movements aren't captured outside of the LWJGL window. I tried setting the System property, dragging, and not dragging but I didn't see a difference from the old behavior.
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.
check the title: inside : [true|false] depending on position of cursor
if you click inside the window and then drag outside while holding the button down, then the coords continue to change outside the window and inside keeps being true until you life the button.
Tested on Windows XP
Hi, this is cool my demo now works without asking any kind of confirmation dialogue at all!
This is one step closer to flash like user experience!
http://www.hot.ee/testgame/appletloader.html (http://www.hot.ee/testgame/appletloader.html)
edit: at least i dont have to sign it with my own cert so it only has lwjgl confirmation.
Quote from: indexunknown on November 16, 2009, 11:43:30
now works without asking any kind of confirmation dialogue at all!
:o that should not happen.
Just tried it and there is a confirmation dialog, you probably accepted dialog box with check box ticked (ticked by default).
if he has approve the LWJGL cert - then all LWJGL games will run without confirmation.
Specifically, since he is not using any native code or anything that requires advanced permissions (like deliting data) then thats all fine and dandy.
and capture mouse seems to work a treat in that test
QuoteSupport 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 :(
Quote from: Mickelukas on November 16, 2009, 18:14:02
QuoteSupport 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.
hi, sorry if this doesnt fit in this thread. but is it now possible to use a classic awt MouseMotionListener to get the mouseevents?
at the moment when i try it with 2.2.1 and add a mousemotionlistener to my AWTGLCanvas i dont get any events. but maybe im doing something wrong?
I'm using a mouse input adapter. To get all drag working, check that you must register a MouseListener and a MouseMotionListener (which are implemented by a mouseInputAdapter class). e.g. I make a rectangular selection and i can drag my picture shown in the AWTGLCanvas like that :
currentCropper = new MouseInputAdapter() {
long hash = System.nanoTime();
public int hashCode() {
return (int) hash;
}
public boolean equals(Object o) {
return o == null ? false : o.hashCode() == hashCode();
}
Point drag = null;
@Override
public void mouseMoved(MouseEvent e) {
super.mouseMoved(e);
if (JXAenvUtils.env.OS_MAC.isEnv() ? e.isMetaDown() : e.isControlDown()) {
e.getComponent().setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
} else {
e.getComponent().setCursor(Cursor.getDefaultCursor());
}
}
@Override
public void mousePressed(MouseEvent e) {
super.mousePressed(e);
String current = photoKey;
if (JXAenvUtils.env.OS_MAC.isEnv() ? !e.isMetaDown() : !e.isControlDown()) {
imageCollectionInfo.get(current).put(INFO_CROPRECT, new Rectangle());
e.getComponent().setCursor(Cursor.getDefaultCursor());
} else {
e.getComponent().setCursor(Cursor.getPredefinedCursor(Cursor.HAND_CURSOR));
}
drag = e.getPoint();
drag.setLocation(
Math.min(cphotoBounds.getMaxX(), Math.max(cphotoBounds.getMinX(), drag.x)),
Math.min(cphotoBounds.getMaxY(), Math.max(cphotoBounds.getMinY(), drag.y)));
drag.x -= cphotoBounds.x;
drag.y -= cphotoBounds.y;
}
@Override
public void mouseDragged(MouseEvent e) {
super.mouseDragged(e);
boolean cropping = JXAenvUtils.env.OS_MAC.isEnv() ? !e.isMetaDown() : !e.isControlDown();
String current = photoKey;
Rectangle r = imageCollectionInfo.get(current).containsKey(INFO_CROPRECT) ? (Rectangle) imageCollectionInfo.get(current).get(INFO_CROPRECT) : null;
Point edrag = e.getPoint();
if (cropping) {
edrag.setLocation(
Math.min(cphotoBounds.getMaxX(), Math.max(cphotoBounds.getMinX(), edrag.x)),
Math.min(cphotoBounds.getMaxY(), Math.max(cphotoBounds.getMinY(), edrag.y)));
}
edrag.x -= cphotoBounds.x;
edrag.y -= cphotoBounds.y;
if (cropping) {
if (r instanceof Rectangle) {
r.setFrameFromDiagonal(drag, edrag);
}
} else {
moveDrag.setLocation(moveDrag.x + (edrag.x - drag.x), moveDrag.y + (edrag.y - drag.y));
}
}
@Override
public void mouseReleased(MouseEvent e) {
super.mouseReleased(e);
e.getComponent().setCursor(Cursor.getDefaultCursor());
}
@Override
public void mouseClicked(MouseEvent e) {
super.mouseClicked(e);
imageCollectionInfo.get(photoKey).remove(INFO_CROPRECT);
}
};
canvas.addMouseListener(currentCropper);
canvas.addMouseMotionListener(currentCrop);
this is a sample of code from IMCBrowser which you can download a demo version at my project page below (or compile the sources with imcbrowser-2.1, jigaxtended-4.1.1 and jxakernel-1.0.8 available in the next hour...). :)
thanks!
i am doing actually pretty much the same thing, but i dont get any events.
as for the display part, here is how i do that:
Display.setParent( awtglcanvas );
Display.create() ;
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.
Quote from: Matzon on November 16, 2009, 06:58:54
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.
Quote from: Matzon on November 16, 2009, 19:48:17
Quote from: Mickelukas on November 16, 2009, 18:14:02
QuoteSupport 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
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 (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).
Thanks Kai, I'll check it out.
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 (https://www.newdawnsoftware.com/hudson/view/LWJGL/) and let me know if you encounter any issues or if I've missed anything important.
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?
you may add a zero-size buffer .
ByteBuffer b = ByteBuffer.allocate(0);
Quote from: broumbroum on December 17, 2009, 22:47:55
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?
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.
Quote from: spasi on December 18, 2009, 01:35:59
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.
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 ?
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 (http://www.realtech-vr.com/glview/download.html) to confirm it.
QuoteIt 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.
Quote from: spasi on January 07, 2010, 15:34:38
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 (http://www.realtech-vr.com/glview/download.html) 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.