Byte Buffer issue with running lwjgl applet

Started by abcdef, January 22, 2011, 12:42:42

Previous topic - Next topic

abcdef

Hi

I have a simple program that loads up a bsp file and displays the resulting scene using opengl. This works fine when compiling and running on the desktop (I am using a Mac). But when I change the startup to use an applet instead (the lwjgl applet) I get a white screen. On doing some debugging I noticed it was to do with extracting the data from the bsp file.

On the desktop when running

bbuf.position(21080);
System.out.println ("Buf float : " + bbuf.get());
System.out.println ("Buf float : " + bbuf.get());
System.out.println ("Buf float : " + bbuf.get());
System.out.println ("Buf float : " + bbuf.get());

(21080 just so happens to be the offset where the vertices are stored in my bsp file and 4 bytes is the first float I want to extract).

I get populated values but in the applet I get all 0's. Strangely when it starts from the beginning and reads the header details it reads everything correctly.

Although not strictly a lwjgl issue, I was wondering if anyone had seen anything similar with their own experience and if there was a suggested way of getting this to work.


jediTofu

Where are you loading the file from?  It should work fine if loading from within the Jar or the user specifies the location.
cool story, bro

abcdef

Loading from with in a jar using

InputStream is = getClass().getResourceAsStream("/" + filename);


then I load the data

fileLength = is.available();
byteData = new byte[fileLength];
is.read(byteData, 0, fileLength);
ByteBuffer bbuf = ByteBuffer.wrap(byteData);

           
then set the order

bbuf.order(ByteOrder.LITTLE_ENDIAN);


Next step is to load the header data then to use the header data to find the location of the rest of the data. Its the reading of the rest of the data that is causing the issue.

The jar with the bsp file in is signed before I use it. Could this cause any issues?

abcdef

Hi

I have resolved this issue, nothing to do with lwjgl (Sorry for posting the question here!). For those that are interested on the resolution to the issue, it is as follows. It was a bit of a red herring with the applet.

When you load a binary file from a class path with the file not in a jar the following code works fine

fileLength = is.available();
byteData = new byte[fileLength];
is.read(byteData, 0, fileLength);


But when you put the file in a jar file it compresses it and you don't get the same results. The isAvailable () returns the correct value but the is.read doesn't read the whole file. I'm not sure if this is the same on all o/s's but on the mac it reads only 8k. To read the whole file you need to run the read multiple times. The scenario with the file outside the jar it reads everything in one go.

int size = is.available();
            byteData = new byte[size];
            
            
            int pos = 0;
	    while(pos < size) 
            {
                int bitToAdd = is.read(byteData, pos, size - pos);
                pos += bitToAdd;
                        
            }


This now loads up the file properly. It's fine now but I seem to have the problem with opengl not running properly in applets running on macs!!  But at least this issue is now resolved.

broumbroum

Quote from: abcdef on January 23, 2011, 11:52:23
bbuf.order(ByteOrder.LITTLE_ENDIAN);

in a compatible fashion it is :
bbuf.order(ByteOrder.nativeOrder());



/** this is a fast "Maximum Transmission Unit" MTU*/
final int MTU = 65536 * 2;
/* direct buffers for OGL*/
final ByteBuffer bbuf = ByteBuffer.allocateDirect(byteSize).order(ByteOrder.nativeOrder());
final byte[] buf = new byte[MTU];
int r = 0;
while((r = in.read(buf)) != -1) {
/* the 0, r ensures that only the read bytes are written */
     bbuf.put(buf, 0, r);
}
bbuf.flip();

The above code is the general way to read from an inputstream to ogl buffers.
;)