Finally at last! 0.96 released.
This took a bit longer than expected due to some last minute bugs.
Notes about this release:
The new AWT component means that LWJGL now has AWT dependency. However, it isn't actually loaded
unless you use the AWTGLCanvas on Win32. If you want a completely AWT free LWJGL, you will have to
exclude that component, and recompile it yourself. Using the new /delayload option requires a compiler
that supports this.
On Linux AWT support is now required. The reason for this is because LWJGL needs to synchronize with
AWT when using X api calls. This change is not related to the AWTGLCanvas, but rather fixes weird errors
when using LWJGL while at the same time using AWT. This may result in another error:
"symbol awt_FreeDrawingSurface, version SUNWprivate_1.1 not defined in file libmawt.so with link time
reference"
which occurs when you try to run a LWJGL app in a headless environment (such as ssh). We believe this
error is a result of Sun Microsystems not exporting the required symbols when using a headless
libmawt.so
Quick overview of changes:
* Templated backend (internal change, autogenerated (without bloat!) openal and opengl native code)
* Support for AWT via the new AWTGLCanvas
* DevIL support across all platforms
* FMOD support for Linux. Mac OS X still missing in action
* glVertexPointer updated to use strong references
* Timer changed to 1 ms resolution. High performance counters don't work properly on HT and SMP machines.
* OpenGL calls are now context aware
API changes:
org.lwjgl.Sys.log has been moved to a new class org.lwjgl.LWJGLUtils.log so that using the (simple)
logging facility did not invoke a load of the native LWJGL component. The debug attribute has also been
renamed to org.lwjgl.util.Debug. This allows DevIL and FMOD to be used independently of LWJGL.
Please post any issues with this release here.
meh - forgot to mention in the readme, but check out:
org.lwjgl.test.opengl.Gears (needed this one for a long time :D)
org.lwjgl.test.opengl.awt.AWTGears
org.lwjgl.test.opengl.awt.AWTTest
and something whipped up quickly:
org.lwjgl.test.opengl.awt.DemoBox
Hehe, just in time. Great!
Did the test.openal.WaveData get moved, or just removed? I was actually using that for my wave files. :P
Nevermind... just happened on it in the utils package... a much better place for it I would agree. :D
What's happening with the controller API known as the Controller class?
Does the lwjgl input stuff work with AWT?
Or do you have to use AWT inputs?
Yeah - WaveData moved, for logical reasons :)
Controller API will probably come back before 1.0. It was removed coz it only worked on Win32.
AWT Input... hmm - don't actually know.. I suppose it's AWT input...
heh. I think you left out the libopenal.so in the linux version ;)
Hey Matzon... before we get too much further into the bug catching phase, I just wanted to send out another great big THANK YOU to the whole team who've made this release possible. :D
Display mode switching seems to be working perfectly :D
hello guys.
first of all, nice work. i love DevIL support for all platforms.
here is some issues that i have with lwjgl-0.96 on Linux (Fedora Core 3 with java 1.5.0_01-b08):
1) error comes up everytime i quit lwjgl application.
even with org.lwjgl.test.WindowCreationTest, when i try to close window by clicking on close button, java dumps following error:
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0x001cff3c, pid=5824, tid=3086907072
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_01-b08 mixed mode, sharing)
# Problematic frame:
# C 0x001cff3c
#
# An error report file with more information is saved as hs_err_pid5824.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
i first thought this issue as something to do with handling OpenGL context with thread, but i don't know.
2) org.lwjgl.test.opengl.awt.DemoBox seems not working.
window shows up, but as soon as i click on one of options on the left, it seems like nothing is happening, or is this somthing supposed to be happened?
yeah i am getting that also, i am running the newest nvidia drivers on fc3 with jdk_1.5.0_02,
i seem to remember older version of lwjgl also doing this.
Excellent work folks.
I only had to change a couple of things for this update:
1. GLContext.GL_ARB_vertex_buffer_object is now GLContext.getCapabilities().GL_ARB_vertex_buffer_object
2. glBufferDataARB(target, elements, (ByteBuffer)null, usage) is now
glBufferDataARB(target, elements, usage)
and thats it!
Happy 0.96'ing everyone.
Quote from: "Zero"heh. I think you left out the libopenal.so in the linux version ;)
doh - just quickly counted the number of 3rd party natives, and I had fmod in there instead of oal. Will publish a new linux client
Quote from: "tomb"Display mode switching seems to be working perfectly :D
excellent, thanks for updating on this bug
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 :)
Quote from: "numberR"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.
Quote from: "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 :)
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
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...
Quote from: "Zero"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.
uploaded lwjgl 0.96-2 which fixes the linux crash bug.
all platforms have been updated since the fix was in Java code.
Quote from: "BinaryBoy"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.
Quote from: "Matzon"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.
Quote from: "spasi"
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 ?
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!
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?
Quote from: "BinaryBoy"[...]
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.
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.
>Sorry if they removed the Perf timer in java 5.
Yep, it's gone. It's System.nanoTime() now.
Aye sorry I was going to chip in with the solution we talked about on IRC the other night - sleep(1) works perfectly, even with my wierdy hyperthreaded speedstepped laptop! Death to yield(), it no longer cuts the mustard.
And also - we are going to replace sync() and sync2() with a single sync() method based on sync2(), that uses sleep(1). So it should work for everyone, all the time.
Cas :)
Anyone done any research on how sleep(1) acts on different system, and different loads?
I had some weird fps in my q3 map viewer. With sleep(1) I got roughly 60 fps, without it I got 2-300.
I modified the sphere bouncing test that I posted above so that I could change the number of times the sircly is rendered. Also changed it so I could print out how long the sleep took, mesured with the sun.misc.perf. Here is the result:
less than 10 balls, sleep took 1.7ms
10 to 30 balls, inconsistant results
more than 30 balls, sleep took 14ms
You could clearly see that the movent got choppy. The fps dropped from hundreds to 55, just as in my viewer.
Let me know if anyone wan't to see the code, and I'll post it.
If this is correct then I'm not convinced yet that the new timer can be used for all games.
Quote from: "oNyx">Sorry if they removed the Perf timer in java 5.
Yep, it's gone. It's System.nanoTime() now.
I know about nanoTime. Just because they added that don't mean they had to remove Perf. nonoTime don't have to use the performance counter, although it probably does.
It's just that I devlop using 1.4 and was not sure if it still worked on 1.5, since it is in the sun package. Anyway, I tested sun.misc.Perf on 1.5.0_02-b09 runtime and it still works.
Sys.VERSION gives me 0.95 after I installed 0.96. Did I download the wrong files somehow, or got the installation wrong? Or is the string simply not updated? :?:
Never mind, after a reset of the system it reported the right version number. Odd... :oops:
I get a bug report output every time I try to use anything with devIL in 0.96. It worked in 0.95. I noticed that in 0.96 there is no ilInit() anymore. Am I totally missing something?
ilInit was removed coz it's done automatically now - due to some issues with mac.
I am not aware of any issues with devil using 0.96
Nice work. I've modified jPCT to use the AWTGLCanvas as an option and it works just fine even when rendering into multiple Canvas'. Well done!
Understanding the timing issues above, performance doenst seem to be the same. I moved from 092 to 096 and seems very choppy. I set vsync2(60) and a sleep(1).
also (cross post apologies) the getEventCharacter on Keyboard does not return anything, jsut a space as far as I can tell. I have tried removing and replacing Keyboard.poll() to no avail. I understand the keyboard buffer is noe on by default and the method was removed. thoguhts?
Quote from: "MickeyB"
also (cross post apologies) the getEventCharacter on Keyboard does not return anything, jsut a space as far as I can tell. I have tried removing and replacing Keyboard.poll() to no avail. I understand the keyboard buffer is noe on by default and the method was removed. thoguhts?
OS? Does org.lwjgl.test.input.KeyboardTest work for you?
- elias
again apologies for crossing earlier, see: http://www.javagaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1114354959