LWJGL 2.0 Released!

Started by Matzon, October 26, 2008, 09:46:30

Previous topic - Next topic

Matzon

LWJGL 2.0 changes
Major changes
* OpenGL 3 support
* Solaris x86 support (no jinput - solaris doesn't have joystick stuff?)
* fmod and devil removed
* dropped support for windows 9x
* glu moved to lwjgl_util
* glu now uses buffers instead of arrays
* New Display.setParent() feature allows you to embed the Display into an existing AWT canvas.
   For example, this allows for an existing LWJGL based application to be used in an applet without porting to AWTGLCanvas.
   This means the death of AWTInputAdapter
* Mac OS X: Added support for x86_64
* Linux: Using openal-soft instead of the creative (was more or less broken anyway)
* Windows: Using openal-soft instead of creatives.
* Support for lzma and pack200 in appletloader
* Support for showing download speed in appletloader

Minor changes
* no more processMessages at isCloseRequested, isVisible, isDirty and isActive
* Removed 2D OpenGL initialization code from Display. It messes with the implicit, but well-defined, opengl default state and doesn't fit well with multiple context types (gl3 and d3d)
* NV_conditional_render extension added
* Support for GL_LAYER_NV
* Lots of input/focus fixes
* Support for ALC_ENUMERATE_ALL_EXT

Non 2.0 specific changes
* Updated openal-soft to latest, with alsa and oss backend (linux), winmm and dsound for windows.

sparc support would be nice - anyone with a beast like that handy?

Get it here

Remember to donate ;)

mot

Hooray!! Thanks for all the care you put in it.

dronus

Ubuntu Linux/32bit:

Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: Method org.lwjgl.openal.AL10.alEnable(I)V is not declared as native
   at org.lwjgl.openal.AL10.initNativeStubs(Native Method)
   at org.lwjgl.openal.AL.init(AL.java:158)
   at org.lwjgl.openal.AL.create(AL.java:140)
   at org.lwjgl.openal.AL.create(AL.java:104)
   at org.dronus.al.ALUtil.init(ALUtil.java:25)
...

My code worked well on 2.0 rc2. :-( .

mot

dronus, this happened to me too while testing this release - I forgot to point to the new directory with native libraries, so I was using the 2.0 final JARs but 2.0rc2 DLLs. Worked fine after fixing this.

dronus

Well, I replaced all files. Seems an Linux issue, though.

elias4444

Great work! I'm trying it out now! Thank you!

=-=-=-=-=-======-=-=-=-=-=-
http://www.tommytwisters.com

Matzon

there may be some issues with the liblwjgl.so for linux - not sure whats going on - will prob resolve this in a 2.0.1 soon

HappyCat

I've been away from Java and LWJGL for a while - got sidetracked into XNA for a while - damn their shiny trinkets  :-)

Anyway, I'm getting back into Java/LWJGL again but I'm not sure whether to upgrade from 1.1.4 to 2.0 or not.

1.1.4 is working fine for me and most of the changes in 2.0 don't look like they affect me, but my code is all 2D stuff so I'm wondering what the deal is with "removed 2D OpenGL initialization code from Display"?

Larssen

Hi guys,

Thanks very much for this great work!!

I have a small problem, maybe i dont know much about multithreading but,

If i make my main class in GLApp and then call a swing frame, lwjgl draws nicely inside the Jframe..

On the other hand, if i make the Jframe main, and ask it to put GLApp inside of it and run, GLApp runs nicely, but the Jframe freezes...


Am I missing something?

What I do is this:

After drawing the frame, i assign a button these:

GLApp2 g = new GLApp2(getC());
( C is a canvas)

Inside GLApp, the constructor is like this :

public GLApp2(Canvas c) {
       
      
        try {
         Display.setParent(c);
      } catch (LWJGLException e) {
         // TODO Auto-generated catch block
         e.printStackTrace();
      }
      run();
  }

I'd be grateful if u can help

Again, thanks guys, great work.






Fool Running

Wow, I somehow missed this.  :-[
Keep up the good work.  8)

Quoteso I'm wondering what the deal is with "removed 2D OpenGL initialization code from Display"?
The Display.create() used to set up a 2D view the size of the window. OpenGL's normal startup state is a 3D view, I think. This was an inconsistency with OpenGL standards.
The only thing you would need to change if using 2.0 is to make sure that you are setting up the 2D view yourself (simple call to glOrtho(), I think).

QuoteAm I missing something?
Here's my best guess (without seeing all the code):
The code you posted is running as a result of a button press on the JFrame.
The run method is a game loop.
The problem comes in that the game is running in the AWT event thread (because that's what handles the button press). The run method (being a loop) never exits so no more AWT events get processed causing the JFrame to seem like its frozen.

I think you need to start the run loop in another thread so that the AWT event thread can continue.
Programmers will, one day, rule the world... and the world won't notice until its too late.Just testing the marquee option ;D

HappyCat

Quote from: Fool Running on October 31, 2008, 15:26:56
Quoteso I'm wondering what the deal is with "removed 2D OpenGL initialization code from Display"?
The Display.create() used to set up a 2D view the size of the window. OpenGL's normal startup state is a 3D view, I think. This was an inconsistency with OpenGL standards.
The only thing you would need to change if using 2.0 is to make sure that you are setting up the 2D view yourself (simple call to glOrtho(), I think).

Cool, I do that anyway. 2.0 here I come!

dronus

The last days I have some ugly freezes (Ununtu 8.04, Nvidia, Retricted Drivers):
When running an lwjgl awt canvas, and the window gets shuffeld on the desktop, gnome freezes totally. Hovever, a am then able to go to a textmode terminal and kill (SIGKILL) the java process, thus reviving gnome again. This does not happen while the app is used (eg focussed, in foreground etc.).
As this is in the last days only I suspect lwjgl 2.0 release to be the origin.

Larssen

Quote from: Fool Running on October 31, 2008, 15:26:56



Here's my best guess (without seeing all the code):
The code you posted is running as a result of a button press on the JFrame.
The run method is a game loop.
The problem comes in that the game is running in the AWT event thread (because that's what handles the button press). The run method (being a loop) never exits so no more AWT events get processed causing the JFrame to seem like its frozen.

I think you need to start the run loop in another thread so that the AWT event thread can continue.

Hi there, and thanks for your reply :)

Yeah I have read the javadocs of lwgl (I REALLY have to end this habit of using first THEN reading documentation :))

And yeah as you say, it freezes the drawing of JFrame, on the other hand calling the constructor of JFrame from a lwjgl thread works nicely, but slowly. In order to solve that, if you see any slow drawings in Swing applications, a fellow forum user have pointed out to end the directdrawing thingy out. Using it solved the slow redrawing of Swing components.

Again thank you for your comments and ideas.. :) I'll delve on using threads.. :)




Eistoeter

devil was removed? How to load textures now?

numberR