LWJGL 0.96 Released!

[Matzon]

Display mode switching seems to be working perfectly

excellent, thanks for updating on this bug

[aldacron]

One little nitpick (only because it's a pet peeve of mine) - in the res/spaceinvaders directory there is a file 'loose.wav'. It should be named 'lose.wav'. Everywhere these days I am seeing people use 'loose' (as in, the opposite of 'tight', or 'to release or to set free' ["Archers! Loose arrows!"]) when they really mean 'lose' (as in, the opposite of 'win'). It drives me nuts  :shock: But, I realize it's trivial in the grand scheme of things  

[Matzon]

1) error comes up everytime i quit lwjgl application.

Confirming. Crashing in closeDisplay. Elias will probably look at it ASAP and we'll do a .2 release for linux only.

[Matzon]

One little nitpick (only because it's a pet peeve of mine) - in the res/spaceinvaders directory there is a file 'loose.wav'. It should be named 'lose.wav'. Everywhere these days I am seeing people use 'loose' (as in, the opposite of 'tight', or 'to release or to set free' ["Archers! Loose arrows!"]) when they really mean 'lose' (as in, the opposite of 'win'). It drives me nuts  :shock: But, I realize it's trivial in the grand scheme of things  

hehe, right I'll remove file from cvs, commit new one, update java code and commit that too...
Don't expect a new release of 0.96 though :p

[BinaryBoy]

First off thanks for the new release and your continued development and support.

I have the same problem with 0.96 as I had in 0.95.

When AA is forced on in the drivers lwjgl crashes with an open GL out of memory error.  This is true for every setting except 8xS which works great for some reason (although chops the frame rate in half obviously).

None of my games or other 3D apps crash with AA forced on, so I'm assuming this is a conflict between lwjgl and the nvidia drivers ?

Also a new problem I'm having with 0.96 is that Display.sync() appears to have stopped working and sync2() is behaving strangely (halfing the frame rate rather than capping it at the target frame rate and introducing some stuttering).

Any thoughts ?

Specs:
Windows XP
P4 3.06GHz (HT disabled)
1Gig Ram (DDR 333)
Nvidia Geforce 6800GT graphics card with latest drivers (released last week problem with AA also occured on the previously released drivers)

*update* Just confirmed that AA works fine on my laptop with ATI mobility graphics card - seems to confirm that it is a problem with lwjgl and nvidia drivers...

[willdenniss]

Does the lwjgl input stuff work with AWT?
Or do you have to use AWT inputs?

I have created a package name the Hybred Input Abstraction Layer.  I use it to abstract out Keyboard and Mouse inputs for my game (which can run on either JOGL using AWT events, or LWJGL using LWJGL events -- in your case you could use it for AWT/LWJGL events).

One nice feature is that it allows you to use the AWT input system but in the LWJGL style (isKeyDown(), etc), and vice versa.

It's open source (BSD-like licensed) and only the respective AWT and LWJGL plugins have dependancies (any unneeded plugins can simply be removed).

The concept is very simple, but I think it is a very useful package.  You are saved from rewriting your entire input system should you decide to change input API's.

For more information visit:  http://input.jtank.net/

Cheers,

Will.

[Matzon]

uploaded lwjgl 0.96-2 which fixes the linux crash bug.
all platforms have been updated since the fix was in Java code.

[spasi]

When AA is forced on in the drivers lwjgl crashes with an open GL out of memory error.  This is true for every setting except 8xS which works great for some reason (although chops the frame rate in half obviously).

None of my games or other 3D apps crash with AA forced on, so I'm assuming this is a conflict between lwjgl and the nvidia drivers ?

All AA modes work fine here (GeFX, 76.41), either through PixelFormat or by forcing it in the drivers.

I don't think it has anything to do with LWJGL, I'm more suspicious of the, too undertested & too buggy lately, nvidia drivers.

[numberR]

uploaded lwjgl 0.96-2 which fixes the linux crash bug.

i confirmed that the bug has been fixed with lwjgl-0.96-2 on Linux (Fedora Core 3). thanks.

[BinaryBoy]

I don't think it has anything to do with LWJGL, I'm more suspicious of the, too undertested & too buggy lately, nvidia drivers.

Hi Spasi - yes this was my inital reaction as well, however it does only seem to be lwjgl that has this problem so it must be something specific that it is doing that other OpenGL apps aren't...

0.94 worked fine but I'm not sure if it was the upgrade to 0.95 or a driver update that introduced the problem.

The sync problem is a strange one too - could this also be caused by dodgy drivers....? I am getting this behavior on my laptop as well so I suspect not.

Is anybody else experiencing these problems ?

[kappa]

i am also experiancing the Display.sync() problems where the frames run higher then the set amount did'nt happen in lwjgl 0.94 but does happen in lwjgl 0.96!

[Jerome Blouin]

In the release notes you reported the following note:

Quick overview of changes:
* Timer changed to 1 ms resolution. High performance counters don't work properly on HT and SMP machines.

Does it contain Cas's fix about the performance problem with the Timer?

[oNyx]

[...]
Also a new problem I'm having with 0.96 is that Display.sync() appears to have stopped working and sync2() is behaving strangely (halfing the frame rate rather than capping it at the target frame rate and introducing some stuttering).

Any thoughts ?
[...]

That's because of the timer change. I guess you have vsync enabled and miss half of the frames, because sync2 now always waits a tad too long.

You can either set that system property thingy for using the old timer (haven't tried that yet)... or sync to a slightly higher framerate.

Let's see... say you want to sync to 60fps. 1000/60=16.666... 1000/16=62.5. So trying to sync every 16msec would be ideal. Using sync2(63L) should produce a usefull result.

Using msecs directly does make more sense (in that case) imo. A capping method for that could look like this:

private static long timeNow, timeThen=0, timeLate=0;
[...]
public static void syncm(long msec)
{
	long gapTo = msec + timeThen;

	do
	{
		Thread.yield();
		timeNow = Sys.getTime();
	}while(gapTo > timeNow+timeLate);

	if(gapTo<timeNow)
		timeLate = timeNow-gapTo;
	else
		timeLate = 0;

	timeThen = timeNow;
}

You could aswell just do something like Math.floor(1000.0/(double)framerate) for getting the msecs.

[tomb]

The problem with sync is that yielding in a loop don't work that well with the new timer. Use sleep(1) instead. That is a change I think everyone will have to do in their game loop.

Here is a smal complete app that shows the difference:

package sh.tests;

import org.lwjgl.*;
import org.lwjgl.opengl.*;
import org.lwjgl.input.*;

public class LWJGL96Test {
	static boolean useMiscPerf = true;
	static sun.misc.Perf perf = sun.misc.Perf.getPerf();
	static boolean sleep = false;
	
	static long getFreq() {
		if (useMiscPerf) {
			return perf.highResFrequency();
		} else {
			return Sys.getTimerResolution();
		}
	}
	
	static long getTime() {
		if (useMiscPerf) {
			return perf.highResCounter();
		} else {
			return Sys.getTime();
		}
	}
	
	public static void main(String args[]) throws Exception {
		try {
			Display.setDisplayMode(new DisplayMode(640, 480));
			Display.create();
			GL11.glClearColor(0.0f, 0.0f, 1.0f, 0.0f);
			float ballx = 320; 
			float bally = 240;
			float dirx = 250f;
			float diry = 200f;
			long timerFreq = getFreq();
			long lastTime = getTime();
			System.out.println("Use sun.misc.Perf="+useMiscPerf);
			System.out.println("sleep="+sleep);
			while (!Display.isCloseRequested()) {
				GL11.glClear(GL11.GL_COLOR_BUFFER_BIT);
				GL11.glLoadIdentity();
				GL11.glTranslatef(ballx, bally, 0);
				
				while (Keyboard.next()) {
					if (Keyboard.getEventKeyState()) {
						if (Keyboard.getEventKey() == Keyboard.KEY_F1) {
							useMiscPerf = !useMiscPerf;
							timerFreq = getFreq();
							lastTime = getTime();
							System.out.println("Use sun.misc.Perf="+useMiscPerf);
						} else if (Keyboard.getEventKey() == Keyboard.KEY_F2) {
							sleep = !sleep;
							System.out.println("sleep="+sleep);
						}
					}
				}
				
				long now = getTime();
				double timeDelta = (now-lastTime)/(double)timerFreq;
				lastTime = now;
				ballx += (float)(dirx * timeDelta);
				bally += (float)(diry * timeDelta);
				dirx = (ballx > 640 ? -250 : dirx);
				dirx = (ballx < 0   ?  250 : dirx);
				diry = (bally > 480 ? -200 : diry);
				diry = (bally < 0   ?  200 : diry);
				
				float radius = 30;
				GL11.glBegin(GL11.GL_TRIANGLE_FAN);
				GL11.glVertex3f(0, 0, 0);
				for (int i=0; i<=64; i++) {
					double angle = (Math.PI*2*i)/64;
					GL11.glVertex3f((float)Math.sin(angle)*radius, (float)Math.cos(angle)*radius, 0);
				}
				GL11.glEnd();
				Display.update();
				if (sleep) {
					Thread.sleep(1);
				} else {
					Thread.yield();
				}
			}
		} catch (Exception e) {
			e.printStackTrace();
		} finally {
			Display.destroy();      
		}
	}
}

Press F1 to switch between LWJGL 0.96 timer and sun.misc.Perf timer. Sorry if they removed the Perf timer in java 5.

Press F2 to switch between yield and sleep(1)

It is not smooth with LWJGL timer and yield.

[oNyx]

>Sorry if they removed the Perf timer in java 5.

Yep, it's gone. It's System.nanoTime() now.