hello hello!!! i'm very new to sprite ripping and i'm stuck. i'm trying to rip a ds game (dorabase 2 nettou ultra stadium) but all of the information is stored in .bin files and i'm not sure what to do with those?? ideally i'd like to extract the information from those somehow but i have no idea where to even begin trying to understand or decompile it. for the record i do know of the screenshot method and GLintercept but the idea of going through the entire game and reassembling EVERYTHING is overwhelming and would make me scared of missing something, so figuring out the .bin would be ideal. any insight would be useful, all i know about .bin files is that they're difficult to deal with and can be pretty much anything. i posted about this on the site forums here but that led to a dead end, the thread includes a screenshot of the game opened through tinke if that will help anyone
#advice on tackling DS .bin files as a newcomer???
78 messages · Page 1 of 1 (latest)
bin is a generic format
it can really be anything, depending on the software house who made the game
yeah im aware of that at least :( i was wondering what to do about it since the Entire Game is packaged into bin files
or at least it appears that way when i open it with tinke and i don't really know where to go from there
I had a look, it looks like the graphics are in a custom format that's going to be very difficult to deal with. Here's what I could figure out without looking at any code:
Each file in the data has no filename, but its file size (4 bytes) is appended to the start. This is the key to unpacking the files, assuming there is nothing useful in the code
Files are padded with up to 15 bytes, so that the next file's header (the 4 byte thing) always starts on a multiple of 16 bytes
Graphics, and possibly other stuff, are stored in a custom container called PD, which I haven't looked at in detail. At least not compressed.
There are also NTFR (fonts) and SSEQ/SBNK (sounds), which are standard DS files.
Found this in the code
oh thats very interesting!!
do games usually have text in the code like that??? i havent heard of anything like it
also how did you do all this? like what did you look at to get this info :0
It's not super uncommon
You'd open a .bin file in a hex editor to view this stuff
Technically you could open it in notepad but hex editors are far more useful for this stuff
(that is about the extent I know on the matter I'm afraid)
ahh i was afraid of that ^^;;;; i don't have any knowledge of understanding pure binary but i suppose it was inevitable while dealing with this filetype
Takes practice, i've done things like this a few times in the past. There's also a very useful resource called gbatek, it details lots of the concepts shared by DS games.
i'll definitely check that out thank you!!! i was wondering where to start with stuff like this
but the big question...how do you get the data into a usable format from here??
I had another look, and I realised most of the data is actually compressed (LZ10).
I'll post the script I used to split the files up, but I'm too busy to look at it any more for the time being. The result is still really unfriendly, getting any graphics out of it is going to take a lot of trial and error.
this is an immense help still!!! i'll look at the site you reccomended when i get home and try to puzzle it out myself, but i'll be sure to ask here if i have any other questions. oh like how to deal with compression??
Compressed files in this game start with the byte 0x10, I think there's a tool called DsDecmp that will help you with them. the files in PD archives seem to follow this pattern.
1: Unknown file 🤮 (I hope this is tilemap data or else)
2: Graphics data (bitmap linked to palette)
3: Palette (the FF 7F makes it obvious as this is the code for white)
oh ive heard of dsdcmp!! do you know of any guides online for how to use it?? i was suggested to use it before but just ended up getting more confused, and i don't want to trouble you too much
the palette data kinda reminds me of hex codes
It's a command line tool, you type in dsdecmp.exe followed by the name of the file you want to decompress
i think
should i try to decompress the entire game or just the datas.bin file? i'll try the datas.bin but i dunno what to do with it after that
Only certain parts of the datas.bin are compressed, you have to cut them out either manually or with a script
ohh thats why its so tricky
example of compressed file, I've highlighted the compression header
hmmm so like. do i grab the compressed bit and then paste the binary itself into the program? or do i save it as its own file
Yeah it needs to be its own file
and i can save that by making it a .txt file??
like. copy the chunk, paste it into notepad, and then save it? or is it not that simple
Not sure about tinke. The one I personally use is called Imhex
Oh, and you need to know how large each compressed file is, since there are multiple in each PD file. The binary data right after the PD part tells you how large the files are, where to find them, etc.
in the header like what you hilighted?
Before that, it looks like this
So in this one, it looks like there are 2 files. The first one starts at 0x20 so right after the header, and it takes up 0x14694 bytes. The second one starts at 0x146b4 bytes and takes up 0x204 bytes, which should lead us to the end of the file. There are 4 more bytes of metadata for each file, but idk what they mean.
so i just need to figure out where each file starts and ends, isolate it, and decompress it?
and the header is just the top line of any chunk that tells you what's inside?
Yep
Although there are over 5k files.... so you're going to need a script at some point....
yeah goodness gracious >_>;;;;;
i may as well do at least one by hand so i understand what its supposed to look like though
Yeah good idea
When you've got graphics data it should be obvious since there are lots of repeating bytes. Open it up in your fav graphics viewer, like crystaltile2, and see if you can link it to the palette.
example
oh so THATS how its supposed to be used!! i was trying to look at the entire game with it and got confused when it looked like a garbled mess
Does the game have 3D objects? I'm looking at the supposed animation data, but it looks way too big for 2d graphics
it's very possible that 3D objects are used. it's a baseball simulator so the sprites themselves are 2D but i believe the field itself is rendered in 3D, and mmmmaybe the characters have some 3D going on for them to run around it??
when i was attempting to rip the game with GLintercept, i got some grass textures from the field itself so theres definitely Some 3d models going on. though i have heard of 2d sprites being rendered using the 3d engine so it could be that as well
Alright. I think the smaller files near the end of the rom are sprites, and the larger ones that were making me nauseous are actually the 3d stages.
😭 that's good to hear!! i'm not looking to rip the stages so if the sprites are easier to deal with thats a weight off of our shoulders
.bin files, more mysteries... These might not be graphics related
it looks pretty at least!!! kinda reminds me of what ascii art of a window would look like
since the diagonal lines make it look like shines
Going to bed now, good luck
thank you for your help!!! i'm gonna try and use imhex myself since it looks like it breaks things down
have a nice rest!!
ok so i've figured some things out but not all
and by that i mean erm. i downloaded imhex and isolated a random chunk and figured out to make it its own file, which is good, and i relearned how to open dsdecmp which is also good, but i'm stuck on both what command to type to decompress the file and also i don't understand how to find headers or how to read them
i also visited some sites to learn more about binary or hex editing/headers in general but information is scarce at least where i'm looking. i found gbatek and i'm going to keep that around but i also read these sites and they helped a little but weren't what i needed
I'll give you a quick overview of pointers + sizes and how to spot them, since they're involved in the PD file format. A pointer is a number which tells you where a certain piece of data starts in a file, be careful since it is relative to a certain position. For the PD format, this only becomes an issue if you are looking at the entire datas.bin rather than the split out files. In the screenshot below, there are 3 pointers, each one representing a sub-file, which I've highlighted in red. Each one tells you how many bytes to go from the start of the file (where it says PD) in order to reach the sub-file. (All DS data is little endian, by the way, so you need to read each byte backwards.) The first pointer it to offset 0x2C, the part in green, which is obviously a compressed file because 1: it looks like nonsense and 2: it starts with the byte 0x10 which is the magic for this game's compression format.
In order to cut out the file, we also need its size, which is conveniently stored next to the pointer in yellow. Then just go to the location of the pointer, and read the number of bytes indicated by the size.
Also notice that the metadata for each file is grouped into 3 "chunks", of 12 bytes each. (each chunk: 4 bytes unknown, 4 bytes size, 4 bytes pointer). The 3 that I've highlighted in blue supposedly tells you how many "chunks" are placed right after it, and by extension how many files are in this archive.
Sorry if that was a lot to take in!
A useful tip for spotting pointers is that when you view them in a column, they increase in value, while sizes do not.
dont be sorry this is exactly what im looking for!!! i'll see if i can locate a file with it once i'm at my laptop
....wait the split out files...is that what the data splitter is for? should i have put the data file through it earlier?
Yeah, I'm going to have to make a second splitter for the PD files
oh my goodness 😭 thank you for how much you're helping, i can't express that enough
also um!! would you be okay with meeting in the voice channel one day so i can ask a lot of smaller questions or stream my process if need be? i feel like getting the beginner stuff out of the way would flood the chat a lot less but it's alright if not
Maybe at the weekend
yeah!!! because i feel like not being able to figure out how to run the command prompt stuff is too small of a hurdle to make a fuss about here but it's still important in order to get to the end result
when would be a good time? i'm free pretty much whenever
I have some free time now, are you alright doing a private call?