help to read a level file

Contests 4K Game Competition - 2009
#1

I have the following scenario:

Created a level file composed by bytes:


    byte[] levels = { 72, 116, -15, 7, 60, -31, -123, 74, 46, 109 
     ... (I have 255 bytes)

The file was created using the following code:


		FileOutputStream fos = new FileOutputStream("l");
		fos.write(levels);

In my game I’m reading using (HERE IS MY PROBLEM):


		getClass().getClassLoader().getResourceAsStream("l").read(levels);

The code above read bytes 0-255 range which return a different result from my original array (byte type -128-127 range). The values -15 that was previously saved is read as 113… and then some items in my game are not displayed because of this issue…

How can I fix it???

#2

Not sure if there is an easier way, but…

Since the range is now 0-255, then :
-128 (in the original -128-127 range) = 0 (in the 0-255 range) .
0 (in the original -128-127 range) = 128 (in the 0-255 range) .
127 (in the original -128-127 range) = 255 (in the 0-255 range) .

So to convert, subtract 128 from the values is in the level array before you use them to generate your level. [113-128=-15]

#3

I find that quite odd… the byte array saved should be identical to the byte array read in.

perhaps you should provide some more relevant code, incase you are doing something odd…

#4

Java bytes only come in the -128-127 flavour… are you sure they haven’t been read in as ints?

There might be something funny going on with the highest order bit: its 1 for -15 and 0 for 113, but otherwise they’re the same.

#5

Pardon the tangent, but…

That code takes up a whole bunch of space, as it gets converted into something like this:


byte[] levels = new byte[255];
levels[0] = 72;
levels[1] = 116;
levels[2] = -15;
levels[3] = 7;
[...]

My version of javac turns each of those assignments into

dup
bipush  7
bipush  74
bastore

That’s six bytes of (uncompressed) class file per byte in the array, or 1530 bytes for a 255 entry byte array.
(Actually, the first six entries only take up five bytes each thanks to iconst_n)

This would all probably compress really well, but I thought you’d probably want to know anyway.

#6

Nothing strange about it; for convenience the write & read methods of Streams accept & return integer types, however only the lowest 8 bits of the integer are used.

Regarding your question, you simply need to cast the returned value to a byte.

FYI the rules for integer casting are below:
Narrowing conversions are performed by truncation.
Widening conversions are performed by sign extension.

Ergo:


int i1 = 255; //0x000000FF
byte b = (byte)i1; // 0xFF (-1)
int i2 = (int)b; // 0xFFFFFFFF (-1), The explicit (int) cast is unnecessary, but included for clarity
#7

@Markus, please note that the level information is stored in a file which size is 255 bytes (I have 255 levels, 1 byte per level). And I’m using a read(byte[]) function to read the file. So I won’t be losing all those bytes.

@Abuse, I’m not sure how to get the cast to work. Take this example: in the original byte array that I use to save the file I have a value -15 but when I read it already returns as 113 so the cast won’t work because I don’t have the original value (-15). If I change my array to integer then the read function won’t accept it because it’s expecting a byte array.

I need to store them as bytes to save space. I need a function to read byte and not integer but I was not able to find such function in the IO package.

Not sure if I was clear enough. I’ll post an example code when I get back to home…

#8

Oh, I see. =D

Although the overhead of an extra file might be bad anyway, since zip compresses files individually and you need to reference several long class and method names to be able to load the data.

#9

Oh, you’e using the byte[] read/write methods - I should have read more carefully :wink:

You must have a bug somewhere; I doubt it’s coincidence that -15 in a byte is 11110001, and 113 is 01110001

#10

yep… that was a bug in my automated ant script to generate the obsfuscated version of the file… it was getting the previous version of my level file… :-X

sorry… :persecutioncomplex: