Norbert wrote:It can't be easy to figure out how the graphics are stored?
I already have programs that can extract full-screen images and some sprites.
I just didn't "convert" them into documentation yet.
I wanted to post levels-related stuff first, and the rest can wait.
Norbert wrote:
Can you roughly describe how you managed to find out certain things.
For instance, that levels have a width and height.
Specific tools you used?
I don't remember all the details, because it was so long ago...
I certainly used the file viewer built into Total Commander.
Any hex-editor is good if it shows all bytes as different characters, including 0x00-0x1F, instead of just showing dots.
Example:
viewtopic.php?p=14068#p14068
Adjustable width is also necessary.
It's also good if I can scroll in a way that allows any byte to be positioned in the top-left corner. BIEW can do that, for example.
I usually just scroll through the file and search for anything that looks interesting.
Repetitions. Patterns. Things that would look better with a different width.
Various types of binary data are recognizable to the trained eye.
Savestates can also help, especially if a game uses compression. So you can compare the compressed and the decompressed data.
And you can see what data gets into Video RAM: palettes, tiles, maps... so you can search for them in the ROM.
If I know for certain the address where something begins, I can also search for that address.
This might lead to a table of pointers.
It helps if you know the format of pointers on the system. (The SEGA Genesis is pretty straightforward in this respect.)
The table might contain other stuff between the pointers. Like an array of structs with the pointer in one field.
And I try to figure out what the other fields are. In case of the levels, I tried to correlate them with what I saw on the maps.
The level type field was easy to recognize. The level sizes not so, but I think the round numbers helped.
I frequently write programs that dump these in a more readable format.
Or I might search for bytes with given differences between them.
For example, in PoP1 SNES, after I found out the place where level 6 and level 7 begins, I wrote a small program that finds adjacent/nearby numbers whose difference equals the difference between the two addresses.
It might sound strange, but usually I do disassembly only much later.
Okay, this list is probably not complete, but I think you got the idea.