LWJGL 0.95 Released

Started by Matzon, January 25, 2005, 21:45:18

Previous topic - Next topic

princec

There's no need to enable it any more - because it's always enabled!

Cas :)

elias

Quote from: "OwenButler"As documented in the release changelog here:

http://lwjgl.org/changelog.php

Keyboard.enableBuffer() was removed from the public API.

Questions:

Why was it removed?  Will it resurface elsewhere or is gone for good?

Is there a replacement in 0.95?  It's incredibly handy.

Regards,

Owen Butler

I'm guessing you misunderstand the "removal". It is only removed from the public API, and is now simply private and automatically called from Keyboard.create() (which is called automatically from Display.create()). The buffered functionality is still there. but the explicit enable is just gone.

- elias

OwenButler

Well that is great, thanks!

elias

Quote from: "Zero"I have the same problem numberR mentioned above.  I can get the failed dependecy to go away, but when I try to use javax.imageio.ImageIO.read() to read in PNG files.  It blows up with a newer depenedency failure for the same libmawt.so???? anyone got any ideas?

I am running FC3 on AthlonXP  with jdk1.5.0_01

[edit] I finally got it to work by copying the so's into /opt/jdk1.5.0_01/jre/lib/i385 and taking out  the -Djava.libra.... stuff.  perhaps the jre doesn't know which libmawt to use after some new change to lwjgl? (motif, headless and xawt exist)

I think I found a fix to the problem. Calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib seems to work. The fix is added to CVS, but you can easily add the line to your applications in the meantime.

- elias

numberR

Quote from: "elias"
Quote from: "Zero"I have the same problem numberR mentioned above.  I can get the failed dependecy to go away, but when I try to use javax.imageio.ImageIO.read() to read in PNG files.  It blows up with a newer depenedency failure for the same libmawt.so???? anyone got any ideas?

I am running FC3 on AthlonXP  with jdk1.5.0_01

[edit] I finally got it to work by copying the so's into /opt/jdk1.5.0_01/jre/lib/i385 and taking out  the -Djava.libra.... stuff.  perhaps the jre doesn't know which libmawt to use after some new change to lwjgl? (motif, headless and xawt exist)

I think I found a fix to the problem. Calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib seems to work. The fix is added to CVS, but you can easily add the line to your applications in the meantime.

- elias

it worked for me as well by calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib. is Toolkit.getDefaultToolkit() necessary for all AWT application?

elias

Quote from: "numberR"
it worked for me as well by calling Toolkit.getDefaultToolkit() before loading the lwjgl native lib. is Toolkit.getDefaultToolkit() necessary for all AWT application?

No. Any AWT call (creating a Canvas would do the trick too) will initialize AWT the same way. Toolkit.getDefaultToolkit() is just one way to do it.

- elias

numberR

i see. anyway, thanks for finding solution for the problem and the fix to CVS.