I'm trying to write a program for ripping sprite tiles directly from the .rom file, without having to go through a program like Desmume and deal with the complications and limitations it presents. I'm trying figure out how people interpret the game files so they can write algorithms to open or rip them.
(07-24-2019, 10:28 PM)TheMarinersRevengeSong Wrote: [ -> ]I'm trying to write a program for ripping sprite tiles directly from the .rom file, without having to go through a program like Desmume and deal with the complications and limitations it presents. I'm trying figure out how people interpret the game files so they can write algorithms to open or rip them.
It's a...complicated process
.
Here's what I think they do:
People find what byte order the file uses, and do trial and error to figure out the header. After they successfully detect the header, they then define the type of filestream it is.
Some filestreams are made by the game authors themselves, so if it is encrypted or compressed may make it very difficult to interpret.
The reason why some file types are made by the companies themselves is mainly for protecting their content, hence copyright. But we don't really do that, we just want to use them for art or fan-animations.
Anyway, you have to make the program interpret the data in a specific way so it reads it just like how the rom's code does, which means ignoring the file header, or extracting different segments of it if it's an archived one. (which means multiple headers are in it)
One thing I think that needs to be defined is that there's a difference between systems: ones with and without filesystems.
Ones with filesystems can be much easier, as you kind of have direct contact with the binary data. ZEROLIGHT is correct in saying that one has to define what the binary data means in its context. In this case, whether the binary data is of model vertices, sound samples, or graphic pixels.
Ones without filesystems (ie. ROMs) may be harder, and is probably different. Generally, if a ROM has no filesystem, no identifiable "header" exists, but rather a bunch of tables that point to the data. I believe it's more so reading in tables and getting the properly pointed data (ie. palette + graphics data) in order to create an "extraction".
So, generalizing the idea of writing "ripping tools" is a broad subject: it's a matter of limiting to what you're trying to rip (ie. models or sprites). This of course, may not be accurate; I thought I'd offer up my ideas. though.