Thanks to @MottZilla research I was able to extract the spritesheets of
Richter as PNGs in conjunction with the original palette from
`F_GAME2.BIN`. When the binaries are built, the PNGs are recompiled back
into binary.
In case of modding, it is possible to modify the sprite size to
accommodate bigger or smaller sprites. Although it is not possible to
modify the existing palette as currently we have no way to extract and
rebuild `F_GAME2.BIN`. You would have to modify the palette via hex
yourself. The file `config/splat.us.ric.yaml` shows in which offset the
palette is located. Just for reference, the colour format for the
palette is RGBA5551. It is important that edited PNGs has 16 colours
otherwise the build will fail.
The `padding` field is required to reconstruct some left-over / junk
data that is not part of the data sprite. For the sake of modding, the
`padding` field can be whatever.
I am not sure if `RIC.BIN` pointers can be relocated. If that is the
case you might get a black screen when playing with Richter. It should
be easily fixable though.
The objective is to separate the data that is usually written into `asm/*/data` into separate files. Those will initially be binary files.
There is also an utility that allows to decompress compressed data. The decompressed data is currently not read as we are missing a compression algorithm that matches the original one. I tried writing one in the past: it worked, it re-created similar files but sadly not the same ones. The decompression algorithm is there to allow to do some data mining and understand what the data is and how it is used.
