LWJGL 2.5 Released

Started by Matzon, July 16, 2010, 11:20:05

Previous topic - Next topic

Matzon

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 ;)

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.

Fool Running

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. :-\
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

broumbroum

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?).

Matzon

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>

broumbroum

Alright, I missed that license content. I shall add a link to lwjgl.org as well in my apps.

Faust

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.

kappa

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.

kappa

ok al_version bug fixed in nightly build.

Jens v.P.

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 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

kappa

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 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.

jouvieje

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)

kappa

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).

kappa

ok changes made.

If you have any other remarks do point them out, always trying to make it better :)

Luy

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.

Matzon

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.