LWJGL Forum

This is an important release that fixes a compatibility issue with ATI drivers, specifically 10.x+

2.3

• new: Removed support for indirect buffers as arguments to AL/GL functions
• new: Added missing tokens in GL30 & GL32
• new: Added support for AMD_seamless_cubemap_per_texture & AMD_shader_stencil_export
• fix: Improved compatibility mode detection - Required for all ATI 10.x Drivers.
• fix: Complete overhaul of the linux focus system when using Display.setParent().
• fix: WaveData - updated to use available() on audio stream

https://sourceforge.net/projects/java-game-lib/files/Official%20Releases/LWJGL%202.3/

Remember to donate (http://lwjgl.org/donations.php) ;)

Thank you!!!

Thanks, will update some old tutorial stuff with the new version :)

Keep up the good work! 8)

Kudos guys!  :)

Thanks!

Question... Is there a document somewhere that describes what each of the jars are and when you'd need them?  For example, I am unsure about AppleJavaExtensions.jar and lzma.jar

Quote from: renanse on February 23, 2010, 19:32:13
Question... Is there a document somewhere that describes what each of the jars are and when you'd need them?  For example, I am unsure about AppleJavaExtensions.jar and lzma.jar

Just ask here, i'd be happy to answer :)

AppletJavaExtension.jar is only needed to compile LWJGL (specifically for the macs dependencies), after that its not needed, precompiled jars which everyone uses shouldn't need it.

lzma.jar is only for deployment when using lwjgl applets. The lwjgl AppletLoader (lwjgl_util_applet.jar) uses it to uncompress lzma files, of course applets can use just plain jars (in which case it won't be needed) but if you decide to use .jar.pack.lzma or .jar.lzma files then you'll need to add lzma.jar to your applet class path so the AppletLoader can uncompress those files. Remember pack200 + lzma = super compressed lwjgl applets :)

lwjgl_util_applet.jar contains lwjgl's super magical AppletLoader, this will deploy the lwjgl natives automatically for you when running lwjgl as an applet while at the same time providing a nice loading screen. Optionally supports lzma and pack200 method of shrinking jars. It needs no extra code, controlled fully with just html.

lwjgl_util.jar contains utility class that you may need, including stuff like GLU (for OpenGL), Vector2d, Vector3d (Maths classes).

lwjgl_test.jar contains various tests and demo's, bascially the stuff found on http://lwjgl.org/demos.php

jinput.jar contains the jinput stuff from controllers and stuff

lastly theres lwjgl-debug.jar (eww, the inconsistency by the use of - instead of _ :)) only jar i'm unsure off but guess its something to do with debugging :)

Thanks :)

We're getting lots of reports of no sound on OS X after the update. Any ideas?

I just tried out the new 2.3 release on my Mac and the sound was coming out just fine. I was using the slick library for sound.

hmm, could the OS X sound problem be related to this (http://lwjgl.org/forum/index.php/topic,2618.msg15843.html#msg15843).

@Tobias do you have any exceptions in the console? does the above rename trick work?

It's this one - new: Removed support for indirect buffers as arguments to GL functions

AL10.alBufferData checks for direct byte buffer, and throws IllegalArgumentException.

I use Pauls Sound System for audio playback: http://www.paulscode.com/
It apparently uses indirect byte buffer

I'd say this change is not very backwards compatible :(

we are very aware of the back compatibility problem, but the performance issues outweighed the change to:
bufferutils.create*().put().flip()

I suggest you get an updated library, as the fix is very easy.

Personally, I wasn't aware at that time that this also extended to OpenAL - but since the change was in the generator it, ofcourse, changes the behavior everywhere. I will update the release note accordingly.

In retrospect, we could probably have generate code that issued a warning instead of flat-out failing.

Yeah it was an easy fix, thanks. Note to self: turn speakers on when testing new releases

Hi,
I have trouble with this new release :

>> new: Removed support for indirect buffers as arguments to AL/GL functions

I used to declare non direct buffers, so I had to adapt my code. It now works using small textures, shader loading and so on.

However, when I load big textures (4096*4096 pixels) I get OutOfMemory exception.
I never had this problem with non direct buffers. My application used to load several such textures.

I tried to initiate the JVM using -XX:MaxDirectMemorySize=1024m and -Xmx1024m, but it's still occuring...
damn ! a 4096*4096 ARGB texture is only 64MB.
Any idea what's happening ? Can I initialise a 64MB buffer using "BufferUtils.createByteBuffer(67108864);" ?

By the way, i'm running windows Vista 32bit (Pro) and the lastest version of Java JDK.

Thanks,
Estraven

Tried -Dsun.nio.MaxDirectMemorySize ?

Cas :)

Hi,

It doesn't change anything. I tried on another computer (similar hardware : nvidia GTX 285 on Win Vista 32 - drivers 196.21)
On this other computer, no OutOfMemory, but all 4096x4096 texture aren't loaded. each channel equal to 0 on : ARGB (checked through GLSL shaders)
2048x2048 textures load and display ok...

Finally, on the same computer (GTX 285) but Win 7 - 64bits, it renders ok....

Everything work well on every computers/OS on LWJGL 2.2 and using non direct buffers.
Any other ideas ? I'm quite desperate here...

Thanks,
Estraven

EDIT :

It seems like VM arguments   "-Dsun.nio.MaxDirectMemorySize=1024m -Xmx1024m"  are responsible.
On my 32bit OS, I only have 1500MB free, thus, only  "-Dsun.nio.MaxDirectMemorySize=1024m -Xmx512m" works.
On my 64bit OS, (4GB instead of 3GB) I have 2.3GB of free RAM, thus "-Dsun.nio.MaxDirectMemorySize=1024m -Xmx1024m" is working...
I made the assumption that is was "maximum" size, but was I wrong ?

Anyway, it works again.

Thanks for the good work on LWJGL !

Estraven.

It sounds like a lot. Are you "reusing" the direct bufferers, or are you just allocating new ones for everything. I basically have a small set of direct bufferers that i reuse to send stuff to lwjgl and have not needed to know anything about -Dsun.nio.MaxDirectMemorySize despite using many 100s of megs of textures and vertex data.

I agree, it's a lot of memory... So I spent the past hours to understand what was happening.

I was only reusing small buffers  :-[ (like texture/vbo/shader ID generation)
I changed my texture loading code. Now I use a single buffer, reallocating it only when the current one is too small to fit the texture (and calling System.gc() to free the previous one).
Indeed, now it works without specifying any  MaxDirectMemorySize ...  8)

In fact, here's what happened :
in some cases, I have a lot of non-graphical stuff in memory, so i do need -Xmx512m.
As I was using non-direct buffer, they were allocated within the JVM memory and everything was ok. (even using a huge set of buffers, disallocated automatically by the Garbage Collector.)
But when I switched to Direct Buffer, my code was really wrong !

Thanks for all the answers. It works just fine now !  :)

Estraven.

Can someone update the basic Wiki?

I have

QuoteException in thread "main" java.lang.IllegalStateException: Function is not supported
   at org.lwjgl.BufferChecks.checkFunctionAddress(BufferChecks.java:64)
   at org.lwjgl.opengl.GL11.glBegin(GL11.java:692)
   at Main.main(Main.java:62)

on

Quote// render using OpenGL
           GL11.glBegin(GL11.GL_QUADS);
                GL11.glVertex3f(0,0,pos);
                GL11.glVertex3f(1,0,pos);
                GL11.glVertex3f(1,1,pos);
                GL11.glVertex3f(0,1,pos);
           GL11.glEnd();

With ATI Radeon 5770 on Vista 64.

which page?

http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/display/basicdisplay

and

http://lwjgl.org/wiki/doku.php/lwjgl/tutorials/opengl/basicopengl

as expected the wiki pages work fine ... are you sure you're copying it correctly?
have you created the display prior to making opengl calls?

That's the missing compatibility context bug... Wiki page should maybe be updated to check for its availability. But I think Spasi's fixed the issue in LWJGL itself (as no GL drivers currently don't actually expose GL1.x methods in reality, it was a bug).

Cas :)

Socke, you're either using ContextAttribs somehow or you're running an LWJGL build older than 2.3. With the default Display.create you shouldn't be having this problem with 2.3.

You are right. I have reinstall all and now it starts.

Does this look right?

(http://www.bilder-hochladen.net/files/thumbs/45u7-2p.png) (http://www.bilder-hochladen.net/files/45u7-2p-png.html)