Users browsing this thread: 2 Guest(s)
Super Bubsy Ripping Help
#1
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?
Game Boy Advance forever!
Reply
Thanked by:
#2
Mind uploading the file so I can take a look?
Tsunami Bomb - The Simple Truth
We could run away
Leave behind anything paper
Not knowing where we're going to stay
When there's no Mondays

You're part of me, it's so easy to see the simple truth
When I'm in your arms, I feel safe from harm and sorrow too
You're part of me, it's so easy to see the simple truth
But most of all, nothing couldn't be solved when I'm with you
Reply
Thanked by: puggsoy
#3
https://www.dropbox.com/s/xetpto5kpg32n9...b.fst?dl=0

I took a gander into it with PSPad and the beginning lists a bunch of BMPs, so it definitely looks like it houses something.
Doofenshmirtz: This is a little bit awkward but have you seen my escape jet keys? (Perry nods) What, you have? Well that's great! So where are they? (Perry looks away) You won't tell me? Is this because you don't speak or are you just being a jerk?
~Phineas and Ferb, "One Good Scare Ought to Do It!" (2008)
Reply
#4
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 Smile

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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
Reply
Thanked by: eureka
#5
(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.
Reply
Thanked by: puggsoy
#6
Probably no help here but Tile Molester shows that 8bpp linear, 2D graphics exist in that file.
[Image: 8FJXJ5R.png]
Once there was a way to get back homeward
Reply
Thanked by: puggsoy, eureka
#7
That is helpful, actually. Could you say what the offset is of those graphics?
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
Reply
Thanked by:
#8
0x18D3C0

couldn't find anything else though
Once there was a way to get back homeward
Reply
Thanked by:
#9
(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
Game Boy Advance forever!
Reply
Thanked by:
#10
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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
Reply
Thanked by:
#11
@Puggsoy: Could you upload all the bmps the script spews out?
And the format should be 2D, not 1D.
Once there was a way to get back homeward
Reply
Thanked by:
#12
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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
Reply
Thanked by:
#13
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.
Once there was a way to get back homeward
Reply
Thanked by: puggsoy
#14
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.
Reply
Thanked by: Raccoon Sam, puggsoy
#15
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.
You may have a fresh start any moment you choose, for this thing that we call "failure" is not the falling down, but the staying down. -Mary Pickford
Reply
Thanked by: Ploaj


Forum Jump: