Just in time for summer vacation...
LWJGL 2.5
- OpenGL: Added PixelFormat support for framebuffer CSAA (NV_multisample_coverage, WGL & GLX only).
- OpenGL: Added support for AMD_name_gen_delete, AMD_debug_output and AMD_transform_feedback3_lines_triangles. The AMDDebugOutputCallback class enables query-less message handling.
- OpenGL: Added support for extension aliases.
- OpenGL: Added support for a new Drawable type (SharedDrawable) that shares its context with another Drawable.
- OpenAL: Update to match newer releases (OpenAL-Soft)
- OpenAL: EFX support
- OpenAL: Upgrade to latest OpenAL-Soft (1.12+)
- AppletLoader: Changes to streamline the Applet experience
- AppletLoader: Initial implementation of a proper caching system.
- AppletLoader: Added parameter support for al_windows32, al_windows64, al_linux32 and al_linux64
- AppletLoader: al_bgcolor, al_fgcolor and al_errorcolor have been removed and replaced with boxbgcolor and boxfgcolor
- Linux: Keyboard focus handling broken when using Display.setParent() applets on Ubunutu
- Linux: Support for Compiz's legacy fullscreen workaround
- Linux: Miscellaneous XrandR fixes
- General: Added support for disabling runtime function checks, buffer checks and state tracking. Activated with -Dorg.lwjgl.util.NoChecks=true
Although Mac doesn't cannot use OpenAL-Soft directly, we are aware of being able to use it through a PortAudio backend. This is not provided by LWJGL however.
Download: https://sourceforge.net/projects/java-game-lib/files/
Changelog: http://www.lwjgl.org/changelogs/2.5-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.
Looks like another great release.
Keep up the good work. 8)
Wish I had more time to play with LWJGL again. Too much work, not enough play. :-\
Regarding the license , what text shall be added,? I mean is there any official topic about that , do lwjgl intend to become a trademark? E.g a license file or specific info (lwjgl.org is that all, isn't?).
Quote from: broumbroum on July 17, 2010, 00:46:52
Regarding the license , what text shall be added,? I mean is there any official topic about that , do lwjgl intend to become a trademark? E.g a license file or specific info (lwjgl.org is that all, isn't?).
The license is pretty clear actually:
http://lwjgl.org/license.php
But generally, we'd just like lwjgl to get mentioned in your about page for your product or in the documentation or whatever makes sense for your product.
This is not a trademark or similar issue, we have no plans on pursuing this at all.
We'd simply just like people to follow the license and get some "appreciation" back.
<thinking out loud>On a longer term, this could probably increase our pagerank and thereby the ad income</thinking out loud>
Alright, I missed that license content. I shall add a link to lwjgl.org as well in my apps.
Hi Matzon,
and thanks in advance for the new version of lwjgl!
I just tried the release and mentioned that something is broken with the al_version tag / implementation. Using for example the "appletloader.html" and commenting the parameter al_version in results in the following exception (with <USERDIR>, <HOST> and <al_title> as placeholders):
This occurred while 'Extracting downloaded packages'
java.io.FileNotFoundException: <USERDIR>\Temp\<HOST>\<al_title>(permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.lwjgl.util.applet.AppletLoader.writeVersionFile(AppletLoader.java:786)
at org.lwjgl.util.applet.AppletLoader.run(AppletLoader.java:740)
at java.lang.Thread.run(Unknown Source)
The exception occurs even if a resign the jar-file.
It seems to me that FileNotFoundException points to the cache dir but does not specify a file. Maybe it should be something like: <USERDIR>\Temp\<HOST>\<al_title>\version
Regards,
Faust.
Quote from: Faust on July 21, 2010, 10:49:30
Hi Matzon,
and thanks in advance for the new version of lwjgl!
I just tried the release and mentioned that something is broken with the al_version tag / implementation. Using for example the "appletloader.html" and commenting the parameter al_version in results in the following exception (with <USERDIR>, <HOST> and <al_title> as placeholders):
This occurred while 'Extracting downloaded packages'
java.io.FileNotFoundException: <USERDIR>\Temp\<HOST>\<al_title>(permission denied)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.lwjgl.util.applet.AppletLoader.writeVersionFile(AppletLoader.java:786)
at org.lwjgl.util.applet.AppletLoader.run(AppletLoader.java:740)
at java.lang.Thread.run(Unknown Source)
The exception occurs even if a resign the jar-file.
It seems to me that FileNotFoundException points to the cache dir but does not specify a file. Maybe it should be something like: <USERDIR>\Temp\<HOST>\<al_title>\version
Regards,
Faust.
ah crap. (double crap :) )
found the bug and will fix tonight.
thx for spotting that and reporting it.
guess for now you can just omit the al_version tag since the new al_cache tag (enabled by default) should pretty much provide the same advantage for you.
the new cache system will automatically download only files that have been changed since the last download, so should be more efficient.
ok al_version bug fixed in nightly build.
Great work! Could you update the Eclipse LWJGL-Plugin to 2.5 as well? We (the GEF3D team) have a question in our newsgroup http://www.eclipse.org/forums/index.php?t=rview&goto=548447&th=162110 (http://www.eclipse.org/forums/index.php?t=rview&goto=548447&th=162110) about that, as there seem to exists some problems with ATI cards in elder versions? Is there anything I can do to help you with that?
Cheers,
Jens
Quote from: jpilgrim on July 22, 2010, 08:43:16
Great work! Could you update the Eclipse LWJGL-Plugin to 2.5 as well? We (the GEF3D team) have a question in our newsgroup http://www.eclipse.org/forums/index.php?t=rview&goto=548447&th=162110 (http://www.eclipse.org/forums/index.php?t=rview&goto=548447&th=162110) about that, as there seem to exists some problems with ATI cards in elder versions? Is there anything I can do to help you with that?
Cheers,
Jens
yup the ATI 10.x drivers broke all LWJGL versions prior to 2.3, the 2.3 release of LWJGL fixes this.
As for the Eclipse LWJGL Plugin, not sure who maintains that.
Great the new work on the applet loader.
I've remarked that the applet loader did not garbage the logo and progress bar resource until the applet is closed/destroy.
It could better to free those resources at the applet switch, this could save few memory ;) (approximatly 1mo)
Quote from: jouvieje on July 24, 2010, 00:01:50
Great the new work on the applet loader.
I've remarked that the applet loader did not garbage the logo and progress bar resource until the applet is closed/destroy.
It could better to free those resources at the applet switch, this could save few memory ;) (approximatly 1mo)
great idea, consider this featured added (will do it later today).
ok changes made.
If you have any other remarks do point them out, always trying to make it better :)
Ok I have another remark ;)
There was recently a discussion about Sys.getTime() pointing out that System.nanoTime() behaves much better on some systems. This seems still true for the current release (at least on my Windows 7, x64 system). It would be really cool if Sys.getTime() automatically picked the best solution for the current system.
Unfortunately QPC, has a lot of issues too:
QuoteAs for QPC, I've actually found that it's not a good idea to use QPC in production code, because there are too many machines on which it is unreliable: everything from its rate changing based on processor scaling to random discontinuities due to TSC mismatches between processor cores to periodic large jumps in value. As a result, I now use timeGetTime() for anything that needs to be reliable -- it's lower precision and more expensive, but you can generally rely on it to be stable.
Quote...this bug was giving me subtle stutter and shake on playback, thought I must have a bug until I saw QueryPerformanceCounter running backwards!
QuoteThe fact that QPC is grossly unreliable. Depending on the actual hardware and CPU load, QPC will randomly jump back and/or forth several seconds (in my experience it was usually ~4 seconds).
http://www.virtualdub.org/blog/pivot/entry.php?id=106
http://support.microsoft.com/kb/274323
Now, whether or not this has been fixed in win7, and/or in which combinations of hardware it fails on we do not know. However you are free to make your own wrapper that chooses nanotime over systime.
I just found the following paper: http://algo2.iti.kit.edu/wassenberg/timing/timing_pitfalls.pdf
If I get it right, there is a reliable timer called High-Precision Event Timer (HPET) on current hardware and QPC uses that from Vista on.
Quote from: Luy on July 26, 2010, 21:34:33
I just found the following paper: http://algo2.iti.kit.edu/wassenberg/timing/timing_pitfalls.pdf
If I get it right, there is a reliable timer called High-Precision Event Timer (HPET) on current hardware and QPC uses that from Vista on.
http://en.wikipedia.org/wiki/High_Precision_Event_Timer:
QuoteThe following operating systems are known not to be able to use HPET: Windows XP,[note 2] Windows Server 2003, and earlier Windows versions, Linux kernels prior to 2.6.[note 3]
The following operating systems are known to be able to use HPET: Windows Vista, Windows 2008, Windows 7, x86 based versions of Mac OS X, Linux operating systems using the 2.6 kernel, FreeBSD and OpenSolaris.
Before we can implement a workaround, we need a reliable way of determining if a timer is "wrong" ... ?
Quote from: Matzon on July 27, 2010, 08:12:26
Before we can implement a workaround, we need a reliable way of determining if a timer is "wrong" ... ?
Sure. I'm no expert, but some googling revealed that on linux information about the used timers can be found in /sys/devices/system/clocksource/clocksource0/ or you can try to directly access the HPET as described here: http://blog.fpmurphy.com/2009/07/linux-hpet-support.html
On Windows Vista/7 a device driver is installed if HPET is available, so you could probably check that. See e.g. http://forum.scottmueller.com/viewtopic.php?f=1&t=1284
In NVFramebufferMultisampleCoverage, the variable GL_MULTISAMPLE_COVERAGE_MODES_NV is spelled GL_MULITSAMPLE_COVERAGE_MODES_NV. Unless mulITsampling is a new function, it's spelled incorrectly. xd
Quote from: javalwjgl on July 24, 2010, 20:06:13
ok changes made.
If you have any other remarks do point them out, always trying to make it better :)
Thanks :)
One thing I could suggest as an improvement. It could be great if the applet loader could download and extract in parallel, instead of extracting everything at the end. This could probably speed a little more the loading (of the first run), which is always great.
Hi,
Again a great release! :D
Quote from: Matzon on July 16, 2010, 11:20:05
- General: Added support for disabling runtime function checks, buffer checks and state tracking. Activated with -Dorg.lwjgl.util.NoChecks=true
I've dreamt of this point since a long time.
Quote from: Matzon on July 16, 2010, 11:20:05
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.
Coming to my mind another idea: is there a 3D version of the LWJGL logo available somewhere? ???
Again thanks!
WS
Quote from: wondersonic on August 09, 2010, 18:29:04
Hi,
Again a great release! :D
Quote from: Matzon on July 16, 2010, 11:20:05
- General: Added support for disabling runtime function checks, buffer checks and state tracking. Activated with -Dorg.lwjgl.util.NoChecks=true
I've dreamt of this point since a long time.
Yeah, me too. I tried disabling the checks but found it made no difference... Could you measure the performance impact of the runtime checks?
Quote from: dr_evil on August 12, 2010, 10:54:26
Quote from: wondersonic on August 09, 2010, 18:29:04
Hi,
Again a great release! :D
Quote from: Matzon on July 16, 2010, 11:20:05
- General: Added support for disabling runtime function checks, buffer checks and state tracking. Activated with -Dorg.lwjgl.util.NoChecks=true
I've dreamt of this point since a long time.
Yeah, me too. I tried disabling the checks but found it made no difference... Could you measure the performance impact of the runtime checks?
I guess I didn't make performance tests since 3 months but at the time these checks costed around 10% of the time.