Super Bubsy Ripping Help

[puggsoy]

Due to the reference to RandomAccessFiles, I'm going to assume that it's Java. You'd have to compile it to make a program, so you'd have to download the SDK and such. This isn't all the code anyway, just the data conversion bit. Besides, all it does so far is create a non-RLE version of the file, the palette would still need to be applied to the file separately.

Ploaj also said it doesn't work with all files, which I am going to assume are ones that have one or more 2-byte instruction chunks with $00 as the first byte. I'll try look into these.

[Ploaj]

Ah yes, it's a code snippet from java.
Like Puggsoy said, it's not really useful yet. Once it can decompress all the files, I'll make a bat file to decompress them all.
Then we just need the palette...

I'll look into figuring out how the 00s work too. Don't know if I can actually be too useful at this point, but maybe I'll get a lucky guess again

Edit:
2 quick notes.
Similar to 0x00, there are some that are 0x80 that appear to have a special meaning. I think it may have to do with like reading bytes until you reach a 0x00, then break; and continue.
And some files have a completely different type of compression. The 0x0003 changes to something else. I don't remember it exactly.

[puggsoy]

0x80 doesn't seem to do what you suggested, there isn't always a corresponding 0x80 for each 0x00, and there isn't always an 0x80 before an 0x00. I know what you mean though, they do crop up in some suspicious looking places. On the other hand, it's not unlikely for an RLE length to require to be 0x80 pixels long, so it wouldn't be smart to give it a special meaning.

As for the other compression type, I don't know which files contain anything other than 0x003, other than those uncompressed ones. Can you give some filenames next time you find these?

[Ploaj]

No, I believe 0x80 has a special meaning. Look at STAR100.BMP.
If whenever there is a 0x80, you only need one pixel, not 128.
Having the decompressor write only one byte when there's a 0x80 gives the correct output.

Edit:
I believe all values larger than 127 have a special function. It may be that whenever it's larger than 127, you repeat the next byte by that minus 128.

[puggsoy]

Subtracting 128 from a byte is the same as turning the highest from 1 to 0. For example if I take 0xC8 (200) and toggle the highest bit, I get 0x48 (72). This is the same thing as subtracting 0x80 (128). This means you can get the value by simply masking out the highest bit:

Code:

int loop = file.read() & 7F;

If you're familiar with bitwise operators you'll understand what that means (I'm pretty sure Java uses the same operators, most C derivatives do). Subtracting 128 works just as well of course, but this way you don't have to check if it's larger than 127 first.

In any case, this means that the highest bit is probably some sort of flag. On the one hand, it could simply be a signed integer flag; 0 = positive, 1 = negative (this is how signed integers are always stored, the high bit defines sign). However I don't see how that could have any function here. It might have some other meaning more important to the compression, although I'm not sure what it could be.

[Ploaj]

Yeah, java's bit operators are the same, but I can't just mask it out like that.
I need to first check to make sure it's not a 0xFF. Then I need to add 1 afterwards and stuff.

Do you think maybe 00 just means 1? It could just not be special in the compression. It seems that the ones >0x80 should be what we look at.

[puggsoy]

Oh yeah of course, my bad.

I was thinking about that too, but I don't think 0x00 is simply 1. I mean, if you go to 0x30 in BIGBUBSY.BMP, it looks like you should just skip it (although that doesn't seem to work either). And both 0xFF and 0x80 are already 1. I'm pretty sure it has some sort of function.