LWJGL 2.9.0

[Matzon]

The LWJGL team is proud to present the latest release of LWJGL: 2.9.0

This release contains a complete rewrite of the OS X backend as well as a truckload of miscellaneous fixes. Please consider upgrading ASAP.

This is the first release build since switching to https://github.com/LWJGL/lwjgl

LWJGL 2.9.0

OSX:

   
• Add: Implement native and animated cursor support on OS X
• Add: Implement Mouse.isInsideWindow()
• Add: Cocoa based native Keyboard and Mouse
• Fix: Switched to native Cocoa windowing system for the native Display
• Fix: Dropped pbuffer usage and switched to offscreen FBO's when using CALayer's
• Fix: CALayer positioning and workaround Java 7 bug (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7172187)
• Fix: Workaround Nvidia driver bug which crashed the OS when releasing a shared context by not releasing shared contexts.
• Fix: Modifiers now report the correct side they are pressed. Added 'fn'-key as modifier
• Fix: Allow the use of F16-F19, SECTION, INSERT, HOME, END, DELETE, NUMPADENTER, CLEAR, LMETA keys
• Removed: support for OSX 10.3 and 10.4

Windows:

   
• Fix: focus problems with Display.setParent
• Fix: setIcon will now block until the taskbar icon has updated
• Fix: async state query for missed key events

OpenGL:

   
• Fix: DrawIndirect buffer size checks and removed null-termination checks
• Add: Alternative VertexAttribPointer with ByteBuffer data and explicit type

   
FreeBSD:

   
• Add: Support for compiling - no official binaries.

   
OpenCL:

   
• Fix: updated KHR extensions to OpenCL 1.2

Download: https://sourceforge.net/projects/java-game-lib/files/
Changelog: http://www.lwjgl.org/changelogs/2.9.0-changelog.txt

Remember to donate

Notice: We'd like to remind people to include the copyright, conditions and disclaimer statement for LWJGL in their products, as required by the license. Though we are not about to claim foul in any way, it would be nice to see a link back to lwjgl.org in the credits or documentation at the very minimum.

[void256]

awesome work!    thanks!   

[Simon Felix]

Whoa cool!

Fix: setIcon will now block until the taskbar icon has updated

I couldn't find anything about that change in the changelog or the forum. Can anyone elaborate on why this was changed? (Background: I use setIcon for animations and I'm worried that with this version it'll impact the performance)

[spasi]

You can see the commit here. There's a comment in the source that describes the problem it's trying to fix. It should not be necessary if Display.setIcon is used before window creation, so I'm open to reverting this commit if it creates more issues than it solves.

I wasn't aware that setIcon was used for animated icons. The change will indeed be a problem for animation, on my system it blocks for around 100ms. In any case, we should probably add a separate API for animated icon updates, since we currently make a copy of the input to Display.setIcon(), which is unnecessarily costly in that case. So we could have a cached setIcon with the above change and an uncached setAnimatedIcon without it.

[Simon Felix]

It's not an issue, I can work around the problem. Thanks for the clarification!

Cheers,
Simon

[Fool Running]

Nice job

[badlogic]

Neato, we updated today and all systems are green so far. Throwing it at the users, we'll report back if any issues come up.

Keep up the good work!

[theagentd]

First of all, thanks a lot for all the updates! The latest version fixed a crash I got on OSX! Much appreciated!

Didn't know where to post this, so I'll just revive this thread. I have a number of mapped VBOs that for performance reasons shouldn't be mapped again until they're not in use anymore to prevent a stall. This requires me to count frames before a buffer can be reused, which is a bit inconvenient since I have to remember to call nextFrame() each frame or I'll get a horrible memory leak where new buffers are allocated but never reused or deleted. On the other hand, if I accidentally call nextFrame() multiple times per frame I may encounter performance problems since the buffer isn't left alone for long enough.

What I'm proposing is the ability to add (and remove) listeners to the Display object that'd allow me to automatically call nextFrame() when Display.update() is called. It'd probably be best if there were two different possible events (different listeners?) for pre-update events and post-update events. Although I could theoretically implement this listener system myself, my library has no control over when or how Display.update() is called, so that'd leave it to the user of the library to remember to call the listeners which is exactly what I want to avoid in the first place.

[CodeBunny]

@theagentd: That sounds like the type of situation that should be your job to deal with. I mean, you're controlling the game loop, right? Just call whatever you want during your gameloop.

[Yuri6037]

I'm using now this version for BrickBroken (currently trying to kill slick2d)...

I think LWJGL 2.9.0 is the best version i have seen ! The only problem is the remove of OSX 10.3 and 10.4 support because many of my users of BrickBroken will not been able to play it again (they have MacBook) !