Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  NIO Buffers in JOGL and LWJGL  (Read 6437 times)
0 Members and 1 Guest are viewing this topic.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Posted 2005-01-22 14:59:25 »

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
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2005-01-22 16:22:41 »

Ooh, it shouldn't be able to crash it, even with totally b0rked buffer positions. The GL drivers are supposed to be resilient to this.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #2 - Posted 2005-01-22 19:20:58 »

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6915739c, pid=3992, tid=2564
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode)
# Problematic frame:
# C  [atioglxx.dll+0x15739c]
#

...
<snip>
...

Stack: [0x00030000,0x00070000),  sp=0x0006f7fc,  free space=253k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [atioglxx.dll+0x15739c]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.GL11.glDrawArrays(III)V+0
j  com.skips.engine.client.world.Terrain.renderSurface()V+284
j  com.skips.engine.client.world.Terrain.process()V+1
j  com.skips.engine.client.world.World.render()V+3

... etc etc etc


That always happened in the *2nd* frame for some obscure reason. In theory the 1st and 2nd frame should be identical.

Hope this helps?

Specs:
Card: ATi Radeon 9700pro 128MB
Driver: 4.10 (not too old)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2005-01-22 19:52:49 »

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 Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 757
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #4 - Posted 2005-01-22 20:53:00 »

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 Smiley)

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

Junior Member




Nothing more that... Java games are cool !


« Reply #5 - Posted 2005-01-22 23:18:29 »

Ati... Update your drivers ! OpenGL is broken on ATI cards with old drivers. I know what I mean, I'm running an ATI Tongue

Download and install the last beta drivers (don't worry about the "beta" word, the driver is very stable) asap !

It runs great here.

Chman
Offline Daire Quinlan

Junior Member





« Reply #6 - Posted 2005-02-10 11:52:55 »

Quote
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 Smiley)


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 ?

Thanks,

D.
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #7 - Posted 2005-02-10 13:59:52 »

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.

The init code for a LWJGL app looks like this:

Display.create();

and you can get more complicated from there on Smiley

Cas Smiley

Offline arzi

Junior Newbie




Java games rock!


« Reply #8 - Posted 2005-03-15 07:32:51 »

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.

The rendering is done in render method:

1  
2  
3  
4  
5  
6  
7  
8  
public void render()
{
        GL11.glClear(GL11.GL_COLOR_BUFFER_BIT | GL11.GL_DEPTH_BUFFER_BIT);
        GL11.glLoadIdentity();
        createVertexArray(vQuads);
        for(Quad q: quads) drawQuads(q);
        update();
}


Setting the vertices:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
public void createVertexArray(Vector<Vertex> vList)
    {

        if(vArraySet) return; // for testing, tests if there is anything to be updated to the GL's vertex list

        if(v==null || v.length != vList.size() * 3) // check if the size of the Vector holding the vertices has changed (otherwise no need to make new arrays
       {
            v = new float[vList.size() * 3];
            n = new float[vList.size() * 3];
            t = new float[vList.size() * 2];
        }
       
        for(int i = 0, vCount = 0; vCount < vList.size(); vCount++)
        {
            // fill the array holding vertex coordinates
           int j = i;
            v[i++] = vList.get(vCount).getX();            
            v[i++] = vList.get(vCount).getY();
            v[i++] = vList.get(vCount).getZ();
            if(useTexture)
            {
                // fill the array to hold the texture coords
               float[] texture = new float[2];
                texture = vList.get(vCount).textureArray();
                t[vCount*2] = texture[0];
                t[vCount*2 +1] = texture[1];
            }
           
        }
       
        FloatBuffer vb = filledFloatBuffer(v); // creates and fill the floatbuffer with the specified array

            GL11.glEnableClientState(GL11.GL_VERTEX_ARRAY);        
            GL11.glVertexPointer(3, 0, vb);
           
       
        if(useTexture)            
        {
            FloatBuffer tb = filledFloatBuffer(t); // as above
           
            GL11.glEnableClientState(GL11.GL_TEXTURE_COORD_ARRAY);
            GL11.glTexCoordPointer(2, 0, tb);
           
        }
            vArraySet = true;
       
       
    }


And the method that does the actual rendering:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
    public void drawQuads(Quad q)
    {
       
        if(useTexture)
        {
           if(q.hasTexture())
           {    
               GL11.glEnable(GL11.GL_TEXTURE_2D);
               GL11.glBindTexture(GL11.GL_TEXTURE_2D, q.getTexture());
           }
           else GL11.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 index
       int[] a =q.asArray();                
        IntBuffer ib = filledIntBuffer(q.asArray());        
        if(ib.get(0) == a[0] && ib.get(a.length-1) == a[a.length-1])
        {
            GL11.glDrawElements(GL11.GL_QUADS, ib);
        }
       
    }
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #9 - Posted 2005-03-15 07:50:31 »

you are rewinding/flipping as needed ?

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arzi

Junior Newbie




Java games rock!


« Reply #10 - Posted 2005-03-15 08:01:21 »

Quote
you are rewinding/flipping as needed ?


Yes, filledFloatBuffer flips the buffer before returning it. If it wouldn't, the app wouldn't work fine for  the first thousands of frames Wink
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #11 - Posted 2005-03-15 08:45:36 »

yeah :/
sounds odd though. What method does it fail in ? nglDrawElements?

Offline arzi

Junior Newbie




Java games rock!


« Reply #12 - Posted 2005-03-15 10:42:00 »

Quote
sounds odd though. What method does it fail in ? nglDrawElements?


Yeah,

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.lwjgl.opengl.GL11.nglDrawElements(IIILjava/nio/Buffer;I)V+0
j  org.lwjgl.opengl.GL11.glDrawElements(ILjava/nio/IntBuffer;)V+22

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.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #13 - Posted 2005-03-15 10:47:39 »

I'm leaning towards driver issues or a "mis-managed" buffer.
What graphics card?
If you could ship it all in a zip file and send it to info@lwjgl.org I'll check it with a Radeon 9700 when I get home.

Offline elias

Senior Member





« Reply #14 - Posted 2005-03-15 10:51:45 »

Quote
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 Smiley



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.

- elias

Offline arzi

Junior Newbie




Java games rock!


« Reply #15 - Posted 2005-03-15 12:23:12 »

Quote
I'm leaning towards driver issues or a "mis-managed" buffer.
What graphics card?


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.

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

Senior Member





« Reply #16 - Posted 2005-03-16 06:11:02 »

Quote


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.

- elias

Offline arzi

Junior Newbie




Java games rock!


« Reply #17 - Posted 2005-03-16 08:27:07 »

Quote
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 Smiley
Offline dronus

Senior Newbie




&quot;Der CRC32-Hashwert dieses Satzes ist BA5D7983.&quot;


« Reply #18 - Posted 2005-03-16 12:21:59 »

Hey, WOW!!
I think you just explained my strange bug of older topic
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1110649575
:-)

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 :-)

Offline tom
« Reply #19 - Posted 2005-03-16 13:52:03 »

Quote
Hey, WOW!!
I think you just explained my strange bug of older topic
http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=LWJGL;action=display;num=1110649575
:-)

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.

That is atleast how I understand it.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2005-03-16 15:09:47 »

That is correct.
I wonder if we could provide a safety net here and get glVertexPointer to hang on to a reference to the buffer?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #21 - Posted 2005-03-16 15:16:19 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2005-03-16 21:15:38 »

What we want is a per-context strong reference, not a weak reference.

We also need to remind people to call glVertexPointer with null to clear the reference where necessary. It's not quite like the C API, but then, this is Java.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #23 - Posted 2005-03-17 07:31:15 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #24 - Posted 2005-03-17 08:36:23 »

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.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #25 - Posted 2005-03-17 08:58:48 »

Quote
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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2005-03-17 10:01:00 »

The difference is, Java deallocates your memory for you without your consent or knowledge. This = crash bug, and therefore we will fix this.

Cas Smiley

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (14 views)
2014-08-01 22:53:16

CogWheelz (14 views)
2014-08-01 22:51:43

CopyableCougar4 (15 views)
2014-08-01 19:37:19

CogWheelz (19 views)
2014-07-30 21:08:39

Riven (27 views)
2014-07-29 18:09:19

Riven (16 views)
2014-07-29 18:08:52

Dwinin (14 views)
2014-07-29 10:59:34

E.R. Fleming (35 views)
2014-07-29 03:07:13

E.R. Fleming (13 views)
2014-07-29 03:06:25

pw (44 views)
2014-07-24 01:59:36
Resources for WIP games
by CogWheelz
2014-08-01 18:20:17

Resources for WIP games
by CogWheelz
2014-08-01 18:19:50

List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!