LWJGL 1.0 Released

Started by Matzon, February 04, 2007, 22:31:55

Previous topic - Next topic

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.

Quote from: darkprophet on February 06, 2007, 17:02:24
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


numberR

Quote from: Matzon on February 06, 2007, 19:33:37
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!
Bubblomania - free, online, cute and psychedelic arcade game!
My Blog

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...
Bubblomania - free, online, cute and psychedelic arcade game!
My Blog

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.
=-=-=-=-=-======-=-=-=-=-=-
http://www.tommytwisters.com

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

Quote from: darkprophet on February 11, 2007, 00:18:58
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