LWJGL 1.0 Released

[K.I.L.E.R]

Sorry you're right. OGL 2.1 has already been out.
When I read your post I got a feeling of anxiety and pressure because I've been looking forward to the new object model and it would scare me if I cannot use it.

2.1 is already out and supported by LWJGL, the new object model is 3.0...

Thanks Matzon. I assume there is a chatlog of a lot of the changes?

[Matzon]

suuuure - somewhere here http://echelog.matzon.dk/?lwjgl happy digging

[numberR]

Making LWJGL completely multithread safe (or something like that)
Reason: elias mentioned him wanting to do that... and it seems to be more and more relevant

Removing support for Devil
Reason: Devil is annoying to handle natively and the features it does bring is easily replicated in Java.
People only really use Devil because of its speed, afaik? - maybe its possible to make a fast image loader in Java. Maybe provide tools to preprocess images into something that can be loaded fast?

for multithread safe thing, does it apply for OpenAL as well (i'm not sure if it is safe now or not...)?

for DevIL thing, i agree with that... especially, most of formats supported by DevIL can be added through ImageIO plugins.

[Matzon]

We won't be more MT safe than the underlying api's, it's just  that there are some issues with threading here and there in lwjgl. At least thats what I understand from elias.

Regarding image loading - it's not so much that we need to read many image formats. Devil was introduced because it had faster loading times. The features it added were just frills on top. However with all the native issues we have had and the size of the 3 libs, I dont think we should move in this direction. I much prefer a Java loader - with preprocessing capabilities - that everybody standardizes on.
One could imagine that it could load std. formats via ImageIO, but then be able to output another format that is loaded fast. It's still on the top of my head.

[Evil-Devil]

For those who don't like to write their own custom image loader i think ImageIO and DevIL is enough. DevIL loads many formats from jpeg to DDS. And everyone else can write their own loader as well. As for myself i only use TGA (opt. RLE) and DXTn. I load them with a selfmade loader and write them to a uniform format that my engine understand.

[darkmoon]

I switched to DevIL because loading was waay faster on my Powerbook (more than 5 times). Please don't remove it!

[Matzon]

if we do remove it, we will have a loader that is speedwise comparable, however it might have a lot less input formats.
Nothing has been decided yet though - so do voice your concerns.

[darkmoon]

If I can load PNG and JPG I'll be happy
However, in my experience with the java loading, it was not the actual loading that was slow, but converting the image so OpenGL can use it...

[kappa]

maybe we can have a image loader in the lwjgl util package where we have a single loader like Slick(maybe a fork ), that loaders tga, png, etc.

[elias4444]

Personally, I've been absolutely content with imageIO. I've found that if it's taking too long to load a texture, I probably need to shrink the texture anyway. Even then, I usually preload everything, which I can do in a separate thread if necessary. I also like being able to rely more on Java, as I'm really big on writing everything for cross-platform.

[elias]

Regarding the multithreading support: I want all LWJGL to be multithread safe, eventually. We're almost there, though: The GL and AL functions are thread safe, "for free" because the underlying specs say so, the AWT and Pbuffer stuff is thread safe, and afaik, only Display, Mouse, Keyboard and Cursor are missing, mostly because they were only ever intended to be used in a simple, single threaded environment.

- elias

[darkprophet]

Wasn't Display.processMessages() and Display.swapBuffers() made public in order for Mouse and Keyboard to be handled by a different thread correctly? I vaguely remember coming across this on #lwjgl a while back and you (elias) changed them for me.

[elias]

Wasn't Display.processMessages() and Display.swapBuffers() made public in order for Mouse and Keyboard to be handled by a different thread correctly? I vaguely remember coming across this on #lwjgl a while back and you (elias) changed them for me.

Sort of, they only solve half the problem by enabling multiple threads. However, the application/game still needs to correctly synchronize access to the LWJGL classes.

- elias

[WiESi]

Hi!

I'm experiencing a little bit trouble with the new LWJGL version. When I execute the following code the screen keeps flickering:

package tunnel;

import org.lwjgl.opengl.*;

import static org.lwjgl.opengl.GL11.*;

public class Tunnel {
	
	public Tunnel() throws Exception {
		Display.setTitle("Tunnel");
		Display.setFullscreen(true);
		Display.create();
		glClearColor(1, 0, 0, 1);
		boolean b = true;
		while(!Display.isCloseRequested()) {
			if(b)
				glClear(GL_COLOR_BUFFER_BIT);
			b = !b;
			Display.update();
		}
	}
	
	public static void main(String[] args) throws Exception {
		new Tunnel();
	}
}

When I remove the line "if(b)" it works well. But normally the display should not start flickering if I don't clear the color buffer every frame (at least this worked in previous versions of LWJGL).

Am I doing something wrong because something has changed or is this really a bug?

[elias]

Please state your OS when you report bugs in the future. I'll assume you're on windows in the following.

This problem is probably caused by a change I did that removed the background for LWJGL windows, to maximize compatibility with crappy OpenGL drivers. To avoid seeing the desktop while a fullscreen game loads, LWJGL automatically glClear()s the color buffer and swaps buffers once. Now, the behaviour you're seeing is probably caused by the other buffer in the double buffered OpenGL window being "garbage" since it was never cleared, and there's no defined background color for it (as previous LWJGL versions had).

To conclude, If you glClear() and update() twice before your update() loop, the flickering will probably go away. However, you can never assume that the "previous" contents of the back buffer is intact, so if you don't clear or otherwise fill the back buffer, an OpenGL implementation is free to give you garbage. In most cases the buffers are re-used so you'll find the previous content intact, but you can't portably count on it.

- elias