FloatBuffers

OpenGL Development
#1

This has been pissing me off all weekend, to say the least :smiley:

I’m working through the red book and I’m trying to implement lighting on a object I’ve loaded, looking through the lwjgl source it appears I have to use Floatbuffers to get this working, so a done a bit of searching as I had no idea how to create them.

Anyhoo, I found this bit of code (and a nice debate on the subject ;D) over at the lwjgl forums, however I still can’t get them to work, the console just spits out a big error log if I use this method to create a Floatbuffer, any ideas what I’m doing wrong here?


float[] matSpec       = new float[] {1f, 1f, 1f, 1f };
FloatBuffer mat_spec   = createFloatBuffer(matSpec);

        FloatBuffer createFloatBuffer(float[] array)
      {
            FloatBuffer fbuff = ByteBuffer.allocateDirect(16)
            .order(ByteOrder.nativeOrder()).asFloatBuffer(); 
            fbuff.put(array).flip(); 
            return fbuff; 
      }

cheers all.

#2

What error?
We have a new Util class in LWJGL that creates native buffers of various sorts for you as well :slight_smile: It’s in CVS.

Cas :slight_smile:

#3

Here’s the error, seems a bit odd :slight_smile:
If I comment out all the functions that use floatbuffers, it runs fine.


An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION (0xc0000005) occurred at PC=0x2E76725
Function=Java_org_lwjgl_input_Keyboard_nPoll+0x5
Library=C:\j2sdk1.4.2_01\jre\lib\ext\lwjgl.dll

Current Java thread:
      at org.lwjgl.input.Keyboard.nPoll(Native Method)
      at org.lwjgl.input.Keyboard.poll(Keyboard.java:338)
      at ftw.processKeyboard(ftw.java:195)
      at ftw.mainLoop(ftw.java:156)
      at ftw.execute(ftw.java:116)
      at ftw.main(ftw.java:523)

Dynamic libraries:
0x00400000 - 0x00406000       C:\j2sdk1.4.2_01\bin\java.exe
0x77F50000 - 0x77FF7000       C:\WINDOWS\System32\ntdll.dll
0x77E60000 - 0x77F46000       C:\WINDOWS\system32\kernel32.dll
0x77DD0000 - 0x77E5D000       C:\WINDOWS\system32\ADVAPI32.dll
0x78000000 - 0x7807E000       C:\WINDOWS\system32\RPCRT4.dll
0x77C10000 - 0x77C63000       C:\WINDOWS\system32\MSVCRT.dll
0x08000000 - 0x08136000       C:\j2sdk1.4.2_01\jre\bin\client\jvm.dll
0x77D40000 - 0x77DCC000       C:\WINDOWS\system32\USER32.dll
0x77C70000 - 0x77CB0000       C:\WINDOWS\system32\GDI32.dll
0x76B40000 - 0x76B6C000       C:\WINDOWS\System32\WINMM.dll
0x10000000 - 0x10007000       C:\j2sdk1.4.2_01\jre\bin\hpi.dll
0x00390000 - 0x0039E000       C:\j2sdk1.4.2_01\jre\bin\verify.dll
0x003A0000 - 0x003B8000       C:\j2sdk1.4.2_01\jre\bin\java.dll
0x003C0000 - 0x003CD000       C:\j2sdk1.4.2_01\jre\bin\zip.dll
0x02E60000 - 0x02EC0000       C:\j2sdk1.4.2_01\jre\lib\ext\lwjgl.dll
0x72280000 - 0x722A8000       C:\WINDOWS\System32\DINPUT.dll
0x5ED00000 - 0x5EDC6000       C:\WINDOWS\System32\OPENGL32.dll
0x68B20000 - 0x68B3E000       C:\WINDOWS\System32\GLU32.dll
0x51000000 - 0x51047000       C:\WINDOWS\System32\DDRAW.dll
0x73BC0000 - 0x73BC6000       C:\WINDOWS\System32\DCIMAN32.dll
0x77C00000 - 0x77C07000       C:\WINDOWS\system32\VERSION.dll
0x5AD70000 - 0x5ADA4000       C:\WINDOWS\System32\uxtheme.dll
0x74720000 - 0x74764000       C:\WINDOWS\System32\MSCTF.dll
0x69500000 - 0x6986B000       C:\WINDOWS\System32\nvoglnt.dll
0x688F0000 - 0x688F9000       C:\WINDOWS\System32\HID.DLL
0x76670000 - 0x76757000       C:\WINDOWS\System32\SETUPAPI.DLL
0x76C90000 - 0x76CB2000       C:\WINDOWS\system32\imagehlp.dll
0x6D510000 - 0x6D58D000       C:\WINDOWS\system32\DBGHELP.dll
0x76BF0000 - 0x76BFB000       C:\WINDOWS\System32\PSAPI.DLL

Heap at VM Abort:
Heap
 def new generation   total 576K, used 377K [0x10010000, 0x100b0000, 0x104f0000)
  eden space 512K,  61% used [0x10010000, 0x1005e470, 0x10090000)
  from space 64K,  99% used [0x100a0000, 0x100afff8, 0x100b0000)
  to   space 64K,   0% used [0x10090000, 0x10090000, 0x100a0000)
 tenured generation   total 1408K, used 75K [0x104f0000, 0x10650000, 0x14010000)
   the space 1408K,   5% used [0x104f0000, 0x10502e38, 0x10503000, 0x10650000)
 compacting perm gen  total 4096K, used 1434K [0x14010000, 0x14410000, 0x18010000)
   the space 4096K,  35% used [0x14010000, 0x14176910, 0x14176a00, 0x14410000)

Local Time = Sun Mar 21 15:25:26 2004
Elapsed Time = 0
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_01-b06 mixed mode)
#
#4

that crash is a bit odd, and especially together with the example code you posted since they’re not related at all. Have you enabled buffering or translation on the keyboard?

#5

The code I’m using is pretty much the same as the FullScreenWindowedTest, so I’ve just been relying on that for keyboard creation, haven’t looked at that area of lwjgl yet.

Just found out what line of the code is causing the problems after a bit of commenting out fun :slight_smile:


float[] mat_spec       = new float[] {1f, 1f, 1f, 1f };
float[] mat_shine       = new float[] { 50f };
FloatBuffer matSpec;
FloatBuffer matShine;

//then in the constructor, using the same method as above

matSpec = createFloatBuffer(mat_spec);
matShine = createFloatBuffer(mat_shine);

//in glInit()
GL11.glMaterial(GL11.GL_FRONT, GL11.GL_SPECULAR, matSpec);        
GL11.glMaterial(GL11.GL_FRONT, GL11.GL_SHININESS, matShine);//if I comment out this line the prog runs fine

So there seems to be a problem if I create a float buffer from an array of zero length, why it starts banging on about the keyboard I have no idea.

#6

Hm, looks like we have a memory clobbering problem going on there causing a spurious crash elsewhere. The 0 length buffer is a clue.

Cas :slight_smile:

#7

Bummer, I was hoping it was something I’d done :slight_smile:

Just a few more things that may be of help, in the initialize method, the order was as follows,

findDisplayMode();
Window.create();
glInit();
Keyboard.create();

I changed this around so that glInit was the last method to be called, and the code ran without any errors, but the lighting was none existent, as the object loaded was drawn in solid colour.

Ahh, the joy of ByteBuffers ;D

Good look fixing it.

:wink:

#8

Any news on this problem, has it been fixed yet or is there a work around?

Don’t want to sound too pushy or impatient (sure your all very busy), it’s just meant that I’ve had to tinker about in jogl whilst learning some simple lighting, it’s just not the same with jogl :slight_smile:

I’m not even sure if it’s something I’ll be using when I finally get around to writing a game, but as far as I can see from flicking through the lighting chapter in the red book ‘0’ length arrays seem to be used quite a bit for setting up lighting and it would be a pity if this problem was around for longer than necessary.

Btw, has anyone else had this problem lwjgl?, if not I’m getting a new gfx card this weekend ;D

Cheers

#9

[quote]Any news on this problem, has it been fixed yet or is there a work around?
[/quote]
Well, Elias committed a patch against Keyboard, so that it always checks the size of the supplied buffer when created. However this is an unrelated issue to what you have posted.

Since you haven’t told us what

[quote]matShine = createFloatBuffer(mat_shine);
[/quote]
exactly does, I am fairly certain that any buffer issues from using you createFloatBuffer method lies in that method, because it fails to rewind the buffer.

I typically use these two methods:

[quote] /**

  • Creates a float buffer to hold specified floats
    • strictly a utility method
  • @param size how many floats to contain
  • @return created FloatBuffer
    */
    protected FloatBuffer createFloatBuffer(int size) {
    ByteBuffer temp = ByteBuffer.allocateDirect(4 * size);
    temp.order(ByteOrder.nativeOrder());
return temp.asFloatBuffer();

}

/**

  • Creates a float buffer to hold specified float array
    • strictly a utility method
  • @param array to hold
  • @return created FloatBuffer
    */
    protected FloatBuffer createFloatBuffer(float[] data) {
    FloatBuffer temp = createFloatBuffer(data.length).put(data);
    temp.flip();
    return temp;
    }
    [/quote]
    do they help?

if not, could you please post the full code, alternatively send it to matzon@lwjgl.org

#10

Hi Matzon, I just tried using your methods to create FloatBuffers (rather than the method I posted in the first post of this thread) but the problem is still there.
You can get the source here: http://mysite.freeserve.com/shooterspace/testFB.java

As I mentioned, the bulk of the code is from FullScreenWindowedTest.java, I have been relying on that for window and keyboard creation.

There’s not much I can add that I haven’t pointed out already, the offending line of code in commented on in the glInit() method.

Cheers :slight_smile:

#11

I tried it on my SuSE 9 (after fixing some compile compile errors against current CVS) and it gave this error:

java.lang.IllegalArgumentException: Number of remaining buffer elements is 1, must be at least 4
at org.lwjgl.opengl.BufferChecks.checkBuffer(Unknown Source)
at org.lwjgl.opengl.BufferChecks.checkBuffer(Unknown Source)
at org.lwjgl.opengl.GL11.glMaterial(Unknown Source)
at testFB.glInit(testFB.java:232)
at testFB.initialize(testFB.java:102)
at testFB.execute(testFB.java:81)
at testFB.main(testFB.java:303)

Then I padded the offending buffer so it became 4 floats instead of one, and then it ran without problems (I saw a gray box of some kind).

  • elias
#12

yeah, what he said :slight_smile:

#13

Odd :D, funnily enough I’ve never had that error report but I have tried that hack before and it did run, but the lighting was always very dark. But yep, that seems to do the trick, in the testFB example anyway.

The none problem now is that my old example (which the testFB was copied from) is still displaying the object incorrectly lit, even though all the gl code and buffer creation code is exactly the same?

I think I’ll browse through them both later on, see if I can spot what the problem is/was, damn curiosity :slight_smile:

Cheers guys :slight_smile:

#14

Doh, if anyone’s interested I just found out why the original was version (after hack) was incorrectly lit and all dark’n’stuff, I was scaling the Modelview matrix ::slight_smile:

Btw, are all 0 length buffers going to be created like this? It’s not a big problem but I can see it causing some confusion for newcomers like myself, so it might be worth mentioning in the FAQ, but then again if the new version has the problem caught and reported with an exception, no problem.

Cheers :slight_smile:

#15

Crash now fixed.
That’s what you get for using asserts in the wrong situation :confused:

Cas :slight_smile:

#16

[quote]Crash now fixed.
That’s what you get for using asserts in the wrong situation :confused:

Cas :slight_smile:
[/quote]
I was with you right up until you mentioned “asserts”, but now I’m all lost :slight_smile: