I'm trying to see how are the tiles saved doing some reverse engineering using old roms gfx files (this example trying with snow bros arcade set one) .

This is what I know now :

  • Each color point to a palette which can change (then when you change palette you change that color in tiles).

  • Tiles have a 16x16 size.

I'm a little confused cause when I see the file in an hex editor . I don't know how many bytes are a pixel or how are they order to see the tile.

Any idea of how this works?

有帮助吗?

解决方案 2

I've found the answer (at least at snowbros game):

tiles are saved in 128 bytes.

Being each byte 2 colors (4 bits per color (indexed of course)) and extructured this way:

Hex file:

enter image description here

Of course hex starts at 0 , but i think this is more visual , each celd is a byte (2 pixels).

其他提示

In the absence of any documentation, I'd start by assuming that each pixel is one byte (simply an index into a 256 color palette) and that blocks of (16 x 16) 256 bytes make up one tile.

Now it is entirely possible that there's some header information as well. So, you need to read the offset + 256 bytes and display that using either a loaded palette or just a grayscale palette.

Keep incrementing offset till you get something that looks like a tile. Now test your assumption by reading subsequent tiles (by incrementing offset by 256 bytes thereafter). Of course - if there's other data between tiles, you'll have to do this over again till you determine the stride.

Note that the colors WILL most likely look messed up if you don't load the correct palette. You will have to rely on your pattern recognition skillz.

All that said, you could find an existing open-source emulator for that console and try to reverse-engineer their code to discover the format, too.

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top