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.
Congratulations and big thanks to all LWJGL developers & contributors!
w00t!!!!!!
;D ;D ;D ;D ;D ;D ;D
Yea!!!
Great news, great work ... let's keep Java rollin'!
Hurrah! Many many thanks to all who have contributed :)
Cas :)
Yeah!!!!! 8)
Thanks to all the devs who have been working hard to get this release done :D
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?
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.
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".
I generally agree, however if everybody has their own, why hasn't anyone done some proper vecmath lib (free) ?
I used the vector stuff quite a lot actually. Simply because I was too lazy to look for something else.
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?
2.1 is already out and supported by LWJGL, the new object model is 3.0...
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.
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?
suuuure - somewhere here http://echelog.matzon.dk/?lwjgl happy digging ;)
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.
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.
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.
I switched to DevIL because loading was waay faster on my Powerbook (more than 5 times). Please don't remove it!
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.
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...
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.
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.
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
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.
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
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?
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
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.
Quote from: Matzon on February 06, 2007, 19:33:37
[...]
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