I am making a Bubsy fan game and I came across a file called spr_bub.fst that contains the sprites files. I opened it in a hex editor and it looks like it stores some sprites in the from of bmp files. Does anyone know how I can rip the files from it?
Mind uploading the file so I can take a look?
First 4 bytes are the number of files, it's in little-endian so that's 5F3 = 1523 files. Then there's an array of this length, each element has 17 bytes; 4 for the offset (also little-endian) and 13 for the name (padded on the end with null bytes). So that's 17 * 1523 = 25891 bytes in total. The last file in this array has no name (just all null bytes) and an offset that equals the end of the file, it probably exists as an end of file reference. After that begins the actual file data.
It's good to be back
Unfortunately, these aren't straight-up BMP files, as I can't see any headers. It doesn't look like simple pixel data either. They're probably compressed or in a special format, but that's all I know. I might take a shot at it later today though.
(10-13-2014, 07:28 PM)puggsoy Wrote: [ -> ]Unfortunately, these aren't straight-up BMP files, as I can't see any headers. It doesn't look like simple pixel data either. They're probably compressed or in a special format, but that's all I know. I might take a shot at it later today though.
The first 8 bytes pointed at by an offset are image metadata.
ushort width?
ushort height?
ushort ImageDataLength
ushort unknown (probably image format)
followed by ImageDataLength bytes of what has to be the image data.
Still don't know how to convert the data, though.
Probably no help here but Tile Molester shows that 8bpp linear, 2D graphics exist in that file.
![[Image: 8FJXJ5R.png]](http://i.imgur.com/8FJXJ5R.png)
That is helpful, actually. Could you say what the offset is of those graphics?
0x18D3C0
couldn't find anything else though
(10-18-2014, 04:39 AM)Raccoon Sam Wrote: [ -> ]0x18D3C0
couldn't find anything else though
I think I'll just rip Bubsy in Claws Encounters of the Furred Kind I like Super Bubsy's sprites better, but I guess Super Bubsy is too hard to rip
I made a QuickBMS script to extract all the files:
Code:
# Super Bubsy .fst format
#
# Written by puggsoy
# script for QuickBMS http://quickbms.aluigi.org
get FILES long
math FILES -= 1
for i = 0 < FILES
savepos POS
get OFFSET long
getct NAME string 0x00
set SIZEPOS OFFSET
math SIZEPOS += 4
goto SIZEPOS
get SIZE short
math SIZE += 8
math POS += 17
goto POS
log NAME OFFSET SIZE
next i
It extracts them with the .bmp extension, as that's what the names have, but obviously they won't open in the default viewer. It probably makes it easier to analyse individual files though.
@RaccoonSam: Are there any other settings I need to set in Tile Molester to find these? I've done 8bpp but I'm not getting anything like that at the address you specified.
@Puggsoy: Could you upload all the bmps the script spews out?
And the format should be 2D, not 1D.
Ah cool, I can see it now. But yeah there doesn't seem to be anything else in the same format.
Here are the BMPs. The graphics you found seem to start at PUYRN_01.BMP.
OKAY
Let's take PUYRN_01.BMP. I can view its graphics in Tile Molester fine, but there are eight suspicious bytes before the actual graphics data:
20 00 20 00 00 04 00 00
The sprite itself is 32 pixels wide and tall. 32 is $20 in hex, so it is safe to assume that the first four bytes are width and height bytes.
What's after that, though... 00 04 00 00..... The same bytes are present in every other PUYRN files. They must have something to do with 'compression type' or something.
Palette data is nowhere to be seen.
I uh.
I've got nothing.
Well a hunch maybe – it could be some kind of RLE, as alternating bytes are somewhat common in the compressed files?
The smallest file is STAR5000.BMP, only 28 bytes, maybe we should look into that? Like, eight bytes for the header (probably) leaves us with only 20 bytes to identify.
I was looking at STAR5000.BMP too and came to the same conclusion that it may be some type of RLE compression.
You'll notice that after the 8 byte header, there is a byte followed by a 00. Now to figure out the relation.
The image size is 8x8, so that's 64 pixels.
If it's 8 bits per pixel(Assumption), then we can assume the decompressed filesize will be 64 bytes then, right?
Oh, and that 00 04 is the image filesize, btw. The two bytes after that appear to be related to image type or compression.
Usually a 0x03 or 0x04 that I've noticed. It's 00s in the PUYRN_01.BMP file because it's not compressed.
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.