Prerelease 2 of LWJGL 0.7

[Matzon]

We've released prerelease 2 of LWJGL 0.7. We're basically done for 0.7, but want to make sure everything is fine for the 0.7 release...

head on over to //www.lwjgl.org to get the goods!

I couldn't get WinCVS to produce a changelog, so this will have to wait.

Please report ANY anomalities!

[cfmdobbie]

Converting my stuff now.

Issues/comments:[list=a]

• Do you have a 0.7 Quickstart Guide, just to ease the pain?  Or just a few lines to give us a starting point?
  
• I know we need to flip our buffers now - but when and how do we do that?
  
• Window.create() etc throw Exception!  Yuk! :wink:
  
• Buffer overflow possible in state queries:  glGetFloat(pname, buffer) converts to library call of glGetFloatv(pname, buffer + buffer.position()) - no check whether buffer is large enough to hold queried data.
  [/list:o]
  
  Resolved:[list=a]
• My textures aren't appearing - I suspect an odd effect caused by the new way of handling buffers.  I'll see what I need to change. (Resolution - flip the pixel buffer after reading pixel data from file.)
  
• The mouse appears to be vertically flipped (again)? (Resolution - get over it and stop whinging! :roll:)
  
• glGenTextures - This doesn't take a number of textures to generate any more - how does this get calculated? (Resolution - appears to "just work"?)
  
• glGetFloatv - Now called glGetFloat.  I thought Cas said there'd be a version that returned a single integer, for those times when you really don't want to bother creating a one element buffer just to return a single int? (Resolution - use your own query layer)
  [/list:o]
  
  Edit: Adding and removing issues as I come up with them!

[nala-naj]

i have all of my stuff working... used the loadTextures() method in the Nehe07 port that you can get off of sourceforge...

but the textures are flickering (or i guess some of the triangles are coming in and out).... this didnt happen with 0.6.  in the new Nehe07 port the loadTexture() returns a int [] instead of an int and the render then uses a filter to pick the value to use as the address of the texture.  i have tried rotating the filter in the array and it is always choppy...  

does anyone have any ideas as to why this might be happening?

thanks

[cfmdobbie]

Being A Guide To Porting Code From Pre-0.7 To Pre2-0.7

[list=1]

• The GL class is now abstract and is not instantiated.  Call Window.create(...) instead, with the same arguments you used to call the GL constructor with.
  
  
• Call Window.destroy() instead of GL.destroy().
  
  
• The "maintenance" methods of GL are now part of Window - isMinimised(), isCloseRequested() etc.
  
  
• The gl.tick() method no longer exists.  It has been replaced with Window.update() - call this whenever you would have called tick() before.
  
  
• DisplayMode selection - no change.
  
  
• GLU code - no change; the GLU is still included as of this release.
  
  
• glColor*v - the array versions of many methods no longer exist.  Call the corresponding multiple-argument method.  E.g. glColor3fv(myColor) becomes glColor3f(myColor[0], myColor[1], myColor[2]).
  
  
• glGenTextures - this method no longer takes an argument describing the number of texture names to generate.  If your buffer was created immediately before being used, this method "just works".  If you've been playing with it, or it's larger than the number of texture names to generate, you may need to manually set buffer.position(0).limit(n), where n is the number of names to generate.  An alternative may be buffer.position(n).flip().  (TBC)
  
  
• Mouse/Keyboard input - no change.
  [/list:o]
  
  That's all I've noticed so far.  Please post any additions or corrections.

[Matzon]

cfmdobbie, thanks a lot!! - I'll more or less be copying this text to the 0.7 readme!

I was *very* tired last night, which is why I forgot one REALLY important bit!

Methods passed a buffer, now use position and limits to calculate the number argument. so in glGenTextures you just do a buffer.position(0).limit(1); to create 1 texture.

But this comes at a small price, back in ye old days, when the address of the buffer was passed, it was always passed as the base address. Now you HAVE to make sure that the buffer has had it's position set to the begining of the buffer. This usually involves a buffer.flip() or buffer.rewind()

One small fluke I forgot to mention:
EAX has been disabled in this release, I am working on an update which will make it easier to use - stay tuned.

now, responses:
a) working on a quickstart guide, will be ready for full 0.7 - it will be a set of simple lessons for using LWJGL - NOT OpenGL or OpenAL.
b) always when you pass it to a method. I don't think I've seen a case where I haven't done it
c) yeah, we'll fix that to a proper kind of exception - adding to todo
d) yup, we'll look into that... but it's just that this has ALWAYS been possible - the only way to fix it, is to have a huge Look up table, and assert against the sizes in it.

loadTextures from NeHe comes in two variants - one that returns 1 int and one that returns an array - I just ported chman's nehes... I don't know why it's done like that - simplicity I guess.

need to go to work now - will be following this thread, and posting as needed when I get a chance

[nala-naj]

thanks for the reponses... i will play around with my textures some more tomorrow... i am sure it is just something i am doing wrong in my code... maybe i should move away from bitmaps and use gifs or jpgs that java is more familiar with

i'm looking forward to the 0.7 quickstart on lwjgl... should be very interesting.

btw - thanks for the porting guide cfmdobbie

[nala-naj]

loadTextures from NeHe comes in two variants - one that returns 1 int and one that returns an array - I just ported chman's nehes... I don't know why it's done like that - simplicity I guess.

well, i have rewritten my code to load the textures and pass only one int as the address back and i am still getting the choppy triangles... i mean it looks good for the most part, but you can definitely tell that something is going wrong...

if anyone wants to try to find the bug i have been missing, here is the code for the texture loading... i am happy to share the rest of my code as well, but dont want to bog down the message board unless someone wants to see it...

   private final static int loadTexture(String file) throws Exception {
        Image image = null;
        image = BitmapImage.loadImage(new FileInputStream(file), file);

        // Exctract the image
        BufferedImage textureImage = new BufferedImage(image.getWidth(null), image.getHeight(null), BufferedImage.TYPE_3BYTE_BGR);
        Graphics2D textureGraphics = (Graphics2D) textureImage.getGraphics();
        textureGraphics.drawImage(image, null, null);
        textureGraphics.dispose();

        // Put the image in memory
        ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

        byte data[] = (byte[]) textureImage.getRaster().getDataElements(0, 0, textureImage.getWidth(), textureImage.getHeight(), null);
        scratch.clear();
        scratch.put(data);

        // Create an IntBuffer for the image address in memory
        IntBuffer buffer = ByteBuffer.allocateDirect(4).order(ByteOrder.nativeOrder()).asIntBuffer();

        // Create the texture in OpenGL
        GL.glGenTextures(buffer);

        // Typical Texture Generation Using Data From The Image
        GL.glBindTexture(GL.GL_TEXTURE_2D, buffer.get(0));

        // Linear filtering
        GL.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MIN_FILTER, GL.GL_LINEAR);

        // Linear filtering
        GL.glTexParameteri(GL.GL_TEXTURE_2D, GL.GL_TEXTURE_MAG_FILTER, GL.GL_LINEAR);

        // Generate the texture
        scratch.flip();
        GL.glTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGB, textureImage.getWidth(), textureImage.getHeight(), 0, GL.GL_RGB, GL.GL_UNSIGNED_BYTE, scratch);

        // Return Image Address In Memory
        return buffer.get(0);
    }

btw:  this code will load a milkshape3d ascii model into simple java objects... there is a model that has a simple draw method that renders to lwjgl... i havent been able to find any code that does this, which is why i am writing it... there was a chman port that i found, but it did not support animations, or i coundnt find any support for them... if someone knows about a piece of code that supports milkshape animations in lwjgl i would be happy to use it, otherwise i will keep on working on this and make it available for anyone that wants it...

thanks

[AndersD]

(Newbie alert! ) Maybe it's that you're missing a order(ByteOrder.nativeOrder()) on the following line:

ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

Or is that just a requirement for other primitives (int, float etc)?

[mac]

Hi,

I Updated my RenderTotexture Demo using the newest Release avaible at LWJGL.org

But i got a Exception :

java.lang.UnsatisfiedLinkError: nGetNULLValue

	at org.lwjgl.Sys.nGetNULLValue(Native Method)

	at org.lwjgl.Sys.<clinit>(Sys.java:105)

	at org.lwjgl.Display.<clinit>(Display.java:81)

	at rendertotexture.ConfigFrame.createDisplayModes(ConfigFrame.java:276)

	at rendertotexture.ConfigFrame.<init>(ConfigFrame.java:64)

	at rendertotexture.ConfigFrame.main(ConfigFrame.java:78)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

	at java.lang.reflect.Method.invoke(Unknown Source)

	at com.sun.javaws.Launcher.executeApplication(Unknown Source)

	at com.sun.javaws.Launcher.executeMainClass(Unknown Source)

	at com.sun.javaws.Launcher.continueLaunch(Unknown Source)

	at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)

	at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)

	at com.sun.javaws.Launcher.run(Unknown Source)

	at java.lang.Thread.run(Unknown Source)

You can Launch the Example via Wevbstart via :

http://www.mac-systems.de/rendetottexture.html

Just Click the Blue Button. (actual Windows only)

- Jens

[Matzon]

java.lang.UnsatisfiedLinkError: nGetNULLValue

some kind of versiuon mixup - make sure you have correct version of everything... nGetNULLValue has been removed - so probably some old class files that need to be recompiled...

[nala-naj]

(Newbie alert! ) Maybe it's that you're missing a order(ByteOrder.nativeOrder()) on the following line:

ByteBuffer scratch = ByteBuffer.allocateDirect(4 * textureImage.getWidth() * textureImage.getHeight());

Or is that just a requirement for other primitives (int, float etc)?

thanks for the catch... still didnt fix my missing triangles ... i need to take a closer look to what i ported from 0.6 to 0.7 i guess

[princec]

Just for everyone's information: Alien Flux is now running perfectly under the current CVS build of LWJGL 0.7pre2 so it's looking like it's perfectly stable, and we can expect a proper release at the weekend.

Cas

[nala-naj]

Just for everyone's information: Alien Flux is now running perfectly under the current CVS build of LWJGL 0.7pre2 so it's looking like it's perfectly stable, and we can expect a proper release at the weekend.

Cas

great news! makes me feel that much better that my problems are coming from my code and not from the libraries

[nala-naj]

FYI: i fixed my problem with my flickering triangles.

i was using the example Window.create() method as seen below...

Window.create("window", 50, 50, 640, 480, 16, 0, 8, 0);

but i am using 24bbp bitmaps for textures and the min depth buffer and bpp had to be set to 24 (duh) as follows...

Window.create("window", 50, 50, 640, 480, 24, 0, 24, 0);

i guess for some reason my old code that used lwjgl 0.6 was initializing differently (24 by default)

thanks again for all of you help

[princec]

I advise you to use 16 bit depth buffers for better portability. You will probably get a 24 bit one anyway, but nevertheless...

<edit>Oh, and I also advise asking for 16 BPP as well. Again, it'll give you more if it can.

Cas