The VG Resource

I might have found the palettes buried in the level data.

https://www.dropbox.com/s/anttenflpxi4wc...s.rar?dl=0

(10-22-2014, 05:59 PM)puggsoy Wrote: [ -> ]You guys are correct, the first 8 bytes are a header consisting of 4 short/word (2 byte) values. The first two are probably width and height as you said, and Ploaj is correct about the third being length of the pixel data, as SciresM said (that's what I used to extract them). The third is probably compression, either an identifier or a sort of "key" to be used while decompressing. It looks pretty tricky but I'll see if I can find out any more about it.

As for the palette, it might be the Windows 95 palette (I've heard of PC games using this before). That wouldn't be unlikely for a 8bpp image format, since the palette contains 256 colours. However it's also possible that palettes are stored elsewhere and applied by the game's code, which would be trickier.

There are a few palettes files on the disk files, however, they don't seem related to sprites from that are presented while the game is being played on a level. I could give you a link to the disk files I downloaded if you like.

Not sure if this is helpful, but there is a image of one of the files that is in the spr_bub.fst that is uncompressed. I am going to upload them in a zip file, maybe it will help for compare them. The uncompressed version maybe different though, it was in the disk files for a launch window.

I've tried comparing the files, but I'm not seeing much relation. The decompressed pixel data begins with 5 $A0 bytes (8bpp, the file has a palette) while the compressed file's data begins with 3 $7F00 words/shorts. Even looking at the bit values, I can't see any way to connect them.

Just realised that the dimensions don't match; the uncompressed image is 64x96, while the compressed one says it's 406x250. I'll see if I can find the correct compressed file, that might yield some results.

EDIT: I can't find anything that looks like the proper file, so I've sorta given up on that and decided to just look at the format without it. It certainly looks like some form of RLE but I can't for the life of me figure out how it works. I've noticed that very often, the first byte of the pixel data is equal to the width minus 1; for example in STAR5000.BMP the width is $08, and the first pixel byte is $07. Another file has a width of $2C, the first byte is $2B, and so on.

The compressed one is also larger than the uncompressed one...

Edit:
I'll try with some ideas.
You said you noticed how the first byte of the image appears to be the image width minus 1, yeah? The byte after that is usually 0x00.
Perhaps that means the top of the decompressed image is all 00s. So Transparent.

Another curious thing I noticed while looking at STAR5000 and STAR2000 is, they should be the same size (8x8), but STAR2000 his larger.
So the compression may be a bit tricky to figure out.

That's what I thought might be the case. The issue is, when we try this with our beloved STAR5000.BMP, we hit a snag at 0x10; $FF80. Do the next $FF pixels use index 80? That seems highly unlikely, seeing as there are only $40 pixels in the image.

EDIT: That's a good point about them being different sizes. That actually gives me an idea; it might be a mixture of encoded and absolute RLE, similar to this. It isn't exactly the same though, I've checked.

Aha!
I got something sort of.

That's Bubsy falling backwards, how'd you get it?

It's not really useful to know. I'm not entirely sure why it worked.
The BUB files only contain one image each.


Edit:
Oh hey, our star friend!


(I have no idea what's happening. Suddenly everything is working.)

Edit:
How did this suddenly become so easy?

Wh-

Code please??

It only works on some of the files. It's basically just RLE.
You actually already figured it out :p

I wrote this the first time I looked at the files, but it worked this time for some reason.
(file and newfile are RandomAccessFiles.)

So that's what $FF means. I don't know why I didn't consider that!

If that's the case, then $00 probably has some special function. Maybe it acts as an escape character, much like normal compressed .bmp files, so that the next byte behaves in a specific way.

By the way, is the palette in the level files as Deathbringer suggested?

great thread guys

^^^ This. Awesome work folks!!

(10-23-2014, 11:10 PM)Ploaj Wrote: [ -> ]It only works on some of the files. It's basically just RLE.
You actually already figured it out :p

I wrote this the first time I looked at the files, but it worked this time for some reason.
(file and newfile are RandomAccessFiles.)

Code:

file.seek(0x08);

while (file.getFilePointer()<file.length()){
            
int loop = file.read();
if (loop == 0xFF) loop = 1; else loop += 1;
int let = file.read();
            
for(int i = 0;i<loop;i++) newfile.write(let);
            
}

This may sound stupid, but what language was this code written in. I can't seem to run it.