Today I just succesfully converted a complete application from JOGL to LWJGL. Ofcourse the performance-difference was zero, but I prefer the LWJGL API (no AWT, nomore passing GL references, proper Input API, damn straightforward, and everything I forgot).

One thing I noticed is that JOGL and LWJGL handle nio-buffers in a slightly different way: you have to rewind() your buffers in LWJGL, while JOGL always starts at pos 0, regardless the pos of the buffer.

Took quite a lot of time to find that, as the JVM just crashes the ugly way, without giving any hints.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I've had similair crashes in feedback for this project of mine under JOGL. When specifying a TexcoordPointer then calling DrawArrays without enabling TEXTURE_COORD_ARRAY all hell broke lose (OS crashes).

And end-users normally blame me (they were stupid bugs anyway, so they were right )

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I've had similair crashes in feedback for this project of mine under JOGL. When specifying a TexcoordPointer then calling DrawArrays without enabling TEXTURE_COORD_ARRAY all hell broke lose (OS crashes).

And end-users normally blame me (they were stupid bugs anyway, so they were right )

Bit of a necro here, sorry about that, but I wanted to comment and also ask a few questions. First off, as regards the problem above, I've found in my experience that EVERY OGL driver crashes out if you either do as Skippy did above, or worse still, enable *_COORD_ARRAY and then forget to set your *CoordPointer. I've had this in C++ stuff aswell so i suspect its a driver thing. It is just a stupid coding error for the most part anyway, I've done it many a time. Nothing like a coredump to focus your attention on a bug !

Question wise, I've got a (relatively) complicated app done up using JOGL at the moment for my OpenGL bindings. Haven't looked much at LWJGL so a quick question, porting over to LWJGL will involve how much work. Is it simply a matter of changing a weensy bit of initialization code and some minor variable renaming ? or would it involve a coding ream-job ?? Particularly as regards the input stuff. I grab all the mouse events from my GLCanvas at the moment and pass them up through my own GUI stack. Would this be affected to a great extent ?

Changing the input stuff will be pretty trivial, as we've got the easiest input library in the entire universe.

The GL code is trickier especially if you're using arrays[] as you'll have to convert all the calls over to using direct ByteBuffers/FloatBuffers/IntBuffers - and then you've also got to make sure the position() and limit()s are correct. But it's not really that much of a chore at all.

I'm having a rather strange crash with glDrawElements. It seems that my application (which is a really simple OpenGL test App that only draws a textured quad on the screen) crashes with EXCEPTION_ACCESS_VIOLATION (0xc0000005) after it has run for some time.

I did a little experimentation and it crashes somewhere around frame 12900 with vsync enabled, frame 13700 without vsync and 2500 if I don't set the vertex array pointer with glVertexArrayPointer for every frame.

if(useTexture) {if(q.hasTexture()) { GL11.glEnable(GL11.GL_TEXTURE_2D);GL11.glBindTexture(GL11.GL_TEXTURE_2D, q.getTexture()); }elseGL11.glDisable(GL11.GL_TEXTURE_2D); }// for testing that the array actually hold the right information (to see if the crash would actually happen because the buffer wasn't allocated right// the Quad class just holds the vertex indices that the quad is comprised of and the texture indexint[] a =q.asArray(); IntBufferib = filledIntBuffer(q.asArray()); if(ib.get(0) == a[0] && ib.get(a.length-1) == a[a.length-1]) {GL11.glDrawElements(GL11.GL_QUADS, ib); }

I have downloaded the sources for LWJGL and looked at the code for nglDrawElements, but didn't get much wiser. I suspect it has something to do with the VertexPointers, because misinformation in them seems to lead to similar crashes. What bugs me is that the app works fine for sometime before the crash. I don't think it's the drivers either because another LWJGL app I've made (with pretty much similar code) seems to work fine.

LOL! ATI can't write drivers for toffee can they, the bastards! There are no arguments to glDrawArrays that should cause it to crash except invalid pointers - and LWJGL pointers are never invalid.

Cas

This is not really ATI's fault, since the vertex array api is to blame. When setting up the vertex array pointers with (for example) glVertexPointer you don't specify the array size, since that's not generally checked in C anyway. Because of that, the GL driver is not (easily) able to check the vertex array accesses from glDrawArrays, glDrawElements and friends. In theroy, LWJGL could check them since we have the buffer sizes, but for anything other than glDrawArrays it would involve an iteration over the entire indices buffer.

Note that this only applies to normal vertex arrays. For VBO buffers, the driver knows the sizes since they are created through OpenGL.

I'm thinking mis-managed buffer, because it seems to work on the other app. Graphics card is Nvidia GeForce GX 5200.

I tried removing the vertexpointer setting and it seems to work fine (obviously showing only a blank) screen, so the bug seems to be there. I'll send the code if I don't get it to work before 18 o'clock (EET).

EDIT:

I got it workin now (at least it runs fine after 50 000 frames and I really don't have nerves to watch a white box longer), but I still quite mystified. What I did was move the glDrawElements call from drawQuads method to the createVertexArray method. Somehow something get lost in between these two methods, but I have no idea what.

I got it workin now (at least it runs fine after 50 000 frames and I really don't have nerves to watch a white box longer), but I still quite mystified. What I did was move the glDrawElements call from drawQuads method to the createVertexArray method. Somehow something get lost in between these two methods, but I have no idea what.

Adding the texture still seems to make the app crash after a while.

I think I know why: One function is creating the float buffers, filling them and giving them to OpenGL via glVertexPointer/TexCoordPointer. Then the function returns, the garbage collector reclaims the buffer, but OpenGL _still_ has the pointer assigned. Then you draw from the now reclaimed buffers with glDrawElements and BOOM, crash.

That's the reason that doing it all in one function works - the buffers is not generally garbage collected before the function returns.

I think I know why: One function is creating the float buffers, filling them and giving them to OpenGL via glVertexPointer/TexCoordPointer. Then the function returns, the garbage collector reclaims the buffer, but OpenGL _still_ has the pointer assigned. Then you draw from the now reclaimed buffers with glDrawElements and BOOM, crash.

Ah, of course, you're right. I assumed that glVertexPointer would copy the array to graphic card's memory which it seems was not the case. I think you should mention things like this somewhere, because they are kind of unique to java and therefore dismissed in other general openGL tutorials/books. Or if there is some kind of a "things to remember about java and opengl" article somewhere, please point it to me

For textures, this things would mean that it is NOT allowed, to loose the reference to the pixel-buffer which makes up a texture...-maybe its loaded to gfx-card.. than all is fine-maybe it doesnt fit to gx-card mem so its dumped and reloaded later from main memory.. and if buffer is gc-collected and overwritten than .. BANG.

For textures, this things would mean that it is NOT allowed, to loose the reference to the pixel-buffer which makes up a texture...-maybe its loaded to gfx-card.. than all is fine-maybe it doesnt fit to gx-card mem so its dumped and reloaded later from main memory.. and if buffer is gc-collected and overwritten than .. BANG.

i will check this out in detail.

thanks for this clue :-)

Not related. glVertexPointer gives the OpenGL driver a pointer to your data. The pointer needs to be valid as long as you are using it (with drawArrays or similar). glTexImage2D copies the data. After that you are free to delete the memory where you stored the image. If the driver stores the image on card or in memroy is irrelevant. It is all handled by the driver and it do not use your memory.

Could you potentially hang on to a weak/soft reference to the glVertexPointer'ed data, and test if it ever becomes GC'ed while still bound? All only enabled when asserts/debug flag is specified that is.

Blech. If you're adding strong references then you're moving away from the existing API rather than just trying to trap programmer errors.

And you'll need to do it for colour pointers (with possible secondary colour pointer) and for potentially a large number of texture coord pointers. And if you really want to be consistant you'll need to add a similar thing to all the per-vertex attributes for GLSL as well.

Not moving away from the existing API at all. It just allows us to enforce the implied behaviour that the C API has - namely that the pointer is always valid. To do it properly though we need to ensure the programmer tells the Java wrapper that we've freed the buffer.

I am aware that there are several calls which need this functionality. I think it would be a great addition and aid debugging a lot. We like to try and get rid of C-style errors in the code. I mean, that's why we use direct byte buffers with position and limit now in the first place, instead of the old API where we used int pointers.

Not moving away from the existing API at all. It just allows us to enforce the implied behaviour that the C API has - namely that the pointer is always valid.

But the current version already has the same enforcement that C has - the pointer is always valid at the time glVertexPointer is called. (Actually, considering that in C you could just pass any arbitrary memory address, its already more robust).

Theres nothing to stop you calling glVertexPointer in C and then deleting the referenced data. That might seem unlikely but quite easily done if your gl calls are hidden away in different functions.

Although I can appreciate the aim, I think this is slipping into doing too much behind the scenes. If someone wants a fool-proof API then they can go with Xith/jme etc.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org