Programming => Lightweight Java Gaming Library => Topic started by: Matzon on April 21, 2013, 20:08:22

Title: LWJGL 2.9.0
Post by: Matzon on April 21, 2013, 20:08:22
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




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

Remember to donate (http://lwjgl.org/donations.php) ;)

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.
Title: Re: LWJGL 2.9.0
Post by: void256 on April 21, 2013, 22:35:00
awesome work!  :D  thanks!   ;D
Title: Re: LWJGL 2.9.0
Post by: Simon Felix on April 22, 2013, 09:02:10
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)
Title: Re: LWJGL 2.9.0
Post by: spasi on April 22, 2013, 11:54:58
You can see the commit here (https://github.com/LWJGL/lwjgl/commit/6fd210fdb325b3acec17d46f8bb8d5ee12620785). 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.
Title: Re: LWJGL 2.9.0
Post by: Simon Felix on April 22, 2013, 12:21:50
It's not an issue, I can work around the problem. Thanks for the clarification!

Title: Re: LWJGL 2.9.0
Post by: Fool Running on April 23, 2013, 23:14:03
Nice job 8)
Title: Re: LWJGL 2.9.0
Post by: badlogic on April 30, 2013, 17:39:14
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!
Title: Re: LWJGL 2.9.0
Post by: theagentd on July 11, 2013, 11:28:34
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.
Title: Re: LWJGL 2.9.0
Post by: CodeBunny on July 16, 2013, 10:45:33
@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.
Title: Re: LWJGL 2.9.0
Post by: Yuri6037 on October 24, 2013, 07:48:36
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) !