LWJGL Forum

Programming => Lightweight Java Gaming Library => Topic started by: Matzon on February 04, 2007, 22:31:55

Title: LWJGL 1.0 Released
Post by: Matzon on February 04, 2007, 22:31:55
Yay!

finally at the big 1.0.
Due to some weird errors, I have been unable to tag the 1.0 release. It was build from revision 2737.

grab it here:
http://sourceforge.net/project/showfiles.php?group_id=58488

As always, consider donating (http://lwjgl.org/donations.php) if you use LWJGL.

This marks the beginning of an unstable period where we plan some big changes, stay tuned for more.
Title: Re: LWJGL 1.0 Released
Post by: mot on February 05, 2007, 03:15:57
Congratulations and big thanks to all LWJGL developers & contributors!
Title: Re: LWJGL 1.0 Released
Post by: elias4444 on February 05, 2007, 04:19:35
w00t!!!!!!
  ;D ;D ;D ;D ;D ;D ;D
Title: Re: LWJGL 1.0 Released
Post by: numberR on February 05, 2007, 05:04:56
Yea!!!
Title: Re: LWJGL 1.0 Released
Post by: Sormuras on February 05, 2007, 06:41:45
Great news, great work ... let's keep Java rollin'!
Title: Re: LWJGL 1.0 Released
Post by: princec on February 05, 2007, 11:20:47
Hurrah! Many many thanks to all who have contributed :)

Cas :)
Title: Re: LWJGL 1.0 Released
Post by: Fool Running on February 05, 2007, 18:14:05
Yeah!!!!! 8)
Thanks to all the devs who have been working hard to get this release done :D
Title: Re: LWJGL 1.0 Released
Post by: Orangy Tang on February 05, 2007, 19:39:30
w00t!  ;D

On a slightly related note; given that the GL class was removed since it was basically just fluff, whats the plans for the vector classes? Given that the plans for SIMD (etc.) math ops are forgotten (I assume) are they going to be removed sometime soon as well?
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 05, 2007, 19:46:27
I personally have no plans to remove those, since I assume quite a few use those?
I would still love some simd action, but it really does require some in-depth knowledge, and is probably somewhat fragile.
Title: Re: LWJGL 1.0 Released
Post by: Orangy Tang on February 05, 2007, 22:12:51
Well the vector classes are (IMHO) quite clunky to use, and I suspect most people have their own versions of the vector classes. On the other hand they're functional and tiny. Including them smells a bit like the "and the kitchen sink" approach that Jogl takes (not a good one IMHO), as they're not really "enabling technology".
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 05, 2007, 22:21:58
I generally agree, however if everybody has their own, why hasn't anyone done some proper vecmath lib (free) ?
Title: Re: LWJGL 1.0 Released
Post by: oNyx on February 06, 2007, 03:56:23
I used the vector stuff quite a lot actually. Simply because I was too lazy to look for something else.
Title: Re: LWJGL 1.0 Released
Post by: K.I.L.E.R on February 06, 2007, 14:06:20
I use the LWJGL Vector library *a lot*. It is very useful and I would *love* to see it expanded to include 'n' size square matrices and vectors.
I usually write routines only if I need certain specific ones for a specific purpose(IE: Guassian elimination).

Congratulations on version 1.0. I've been waiting for this for a long time.
May I inquire into the nature of the "big changes"? I'm quite interested in what would be added/changes considering LWJGL's beautiful nature is it's size and simplicity.

EDIT: It just hit me, the big changes are related to OpenGL 2.1 and the new object model and the like?
Title: Re: LWJGL 1.0 Released
Post by: darkprophet on February 06, 2007, 17:02:24
2.1 is already out and supported by LWJGL, the new object model is 3.0...
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 06, 2007, 19:33:37
In the interrest of getting it out in the open, and because not *everybody* is on irc://irc.freenode.net/lwjgl (god knows why, its the BEST channel out there ::))

some of the big changes that we have talked about are:
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 fmod
Reason: Our version is only fmod 3. Its not completely free. Module and ogg support is provided by IBXM and jorbis. Fmod4 support is done by some other guy (swig based, yuck :-*)
May or may not replace this with a simple api to do it all (prefer not, since we would basically be replicating slick - but it would be nice to have a complete package for game development, instead of getting 4325425 packages - your opinion?).

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?

Another planned update is OpenAL 1.1 support though it's not part of the big changes thing.
Title: Re: LWJGL 1.0 Released
Post by: K.I.L.E.R on February 07, 2007, 00:51:18
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?
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 07, 2007, 05:50:51
suuuure - somewhere here http://echelog.matzon.dk/?lwjgl happy digging ;)
Title: Re: LWJGL 1.0 Released
Post by: numberR on February 08, 2007, 23:56:38
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.
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 09, 2007, 06:11:22
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.
Title: Re: LWJGL 1.0 Released
Post by: Evil-Devil on February 09, 2007, 12:24:15
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.
Title: Re: LWJGL 1.0 Released
Post by: darkmoon on February 09, 2007, 14:49:32
I switched to DevIL because loading was waay faster on my Powerbook (more than 5 times). Please don't remove it!
Title: Re: LWJGL 1.0 Released
Post by: Matzon on February 09, 2007, 14:55:58
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.
Title: Re: LWJGL 1.0 Released
Post by: darkmoon on February 09, 2007, 15:12:55
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...
Title: Re: LWJGL 1.0 Released
Post by: kappa on February 09, 2007, 15:21:18
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.
Title: Re: LWJGL 1.0 Released
Post by: elias4444 on February 09, 2007, 16:37:59
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.
Title: Re: LWJGL 1.0 Released
Post by: elias on February 09, 2007, 20:59:48
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
Title: Re: LWJGL 1.0 Released
Post by: 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.

Title: Re: LWJGL 1.0 Released
Post by: elias on February 12, 2007, 09:57:43
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
Title: Re: LWJGL 1.0 Released
Post by: WiESi on February 12, 2007, 13:40:41
Hi!

I'm experiencing a little bit trouble with the new LWJGL version. When I execute the following code the screen keeps flickering:
Code: [Select]
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?
Title: Re: LWJGL 1.0 Released
Post by: elias on February 12, 2007, 14:02:03
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
Title: Re: LWJGL 1.0 Released
Post by: Jon on February 16, 2007, 06:10:48
I'd be interested in seeing a pure-Java loading framework included in LWJGL as opposed to DeviL. If it supported all of the standard formats and some of the less than standard ones (DDS with DXTn compression?), that would be superb.
Title: Re: LWJGL 1.0 Released
Post by: Sormuras on February 28, 2007, 08:31:28
[...]
Another planned update is OpenAL 1.1 support though it's not part of the big changes thing.

Any thoughts about an update/replace of the logging system? I started a feature request over at jMonkeys [1] ... and LWJGL is a library too, that can benefit from letting the library user (game programmer) deploy an implementation as needed.

Cheers,
Sor

[1] http://www.jmonkeyengine.com/jmeforum/index.php?topic=4630.0