LWJGL 1.1 released
Download (http://sourceforge.net/project/showfiles.php?group_id=58488)
Release notes (http://sourceforge.net/project/shownotes.php?group_id=58488&release_id=504946)
As always, consider donating (http://lwjgl.org/donations.php) if you use LWJGL.
Well done!
Awesome work (VBO performance seems much improved on my platform).
- Nicolai de Haan Brøgger
Criminy, you guys have been busy! What brought that flurry of development on?
Cas :)
well, I've been delaying oal 1.1 for a while, guess I caved in.
as for elias, I just think he gets bored sometimes...
Sweet, a new release ;D
Keep up the good work 8)
Great!
awsome, thanx guys keep up the good work :D
Great, thanks to all LWJGL developers. I just sent you a small donation, have a beer or something.
[EDIT] Is it just on my machine or is the Windows mouse acceleration being taken into account when it's in "grabbed" mode? I saw the changes in the ChangeLog but I'm not sure if this is intended. Until now I was doing my own mouse acceleration to compensate because in the "grabbed" mode the cursor was much slower.
Quote from: mot on May 03, 2007, 22:03:15
Is it just on my machine or is the Windows mouse acceleration being taken into account when it's in "grabbed" mode? I saw the changes in the ChangeLog but I'm not sure if this is intended. Until now I was doing my own mouse acceleration to compensate because in the "grabbed" mode the cursor was much slower.
This is expected, since we've gone from using directinput to using windows messages for input, which takes configuration parameters like mouse acceleration into account. The downside is that this is a change from previous LWJGL versions, the upside is that the mouse should now be consistent on all platforms (since acceleration is applied on mac and linux LWJGL input).
@princec: The directinput->windows messages work was needed because multiple mice through JInput don't work when DirectInput is active (this is an inherent flaw in the windows implementation of Raw Input and DirectInput). The non-direct buffer support was inspired because I realized they could be supported with very little (and constant) code size overhead and no performance overhead.
- elias
Quote
Make the rest of LWJGL thread safe. No attempt have been done to make the locking minimal. Instead, one global lock is shared by Display, Mouse, Keyboard and Cursor. The lock surrounds all public methods.
Quote
What exactly do you mean by this? It seems that you have just made it so that LWJGL can be accessed by multiple threads, but isn't that slightly odd seeing as only one thread can have the GLContext at a time? Or do you mean that LWJGL now holds the context and all calls (no matter which thread they are from) end up using the correct context?
To me it sounds like the first, but there doesn't really seem much point to it aside from helping the integrity of the library. I would love to know the reasoning.
You're absolutely right, both OpenGL and OpenAL are thread safe by specification. However, there's still a few bits of LWJGL specific code (Display, Mouse, Keyboard, Cursor) that is not a direct binding to an underlying API. They carry internal LWJGL state and have to be synchronized, which is what the changelog entry refers to.
- elias