I figure this thread is old enough that this may not be an issue anymore, or perhaps this is already figured out, but I was curious if anyone else had come across the ICL, ICG, ISC, and IOB file formats. I recently found out what the structure of these files are, being a format very similar to the earlier ACL, ACG, ASC, and AOB files, but updated for Iris.
ACG files start off as raw character graphics data in either 4bpp or 8bpp format, and are immediately followed by attribute data, with 1 byte per tile specifying which palette each tile uses. After the attribute data is the file footer, containing all the metadata about the file. Similarly, ISC files store raw screen data in either text, affine, or affine extended format. The file footer immediately follows this. The file footer for both of these files follows the same structure, being a string of data blocks starting with a 4-byte signature, 4-byte content length in little endian, and 0 or more bytes of data. As a result of storing the file this way, finding the file footer is a bit of a pain since there is no fixed offset from the beginning or the end of the file where it may occur. A nice consequence of this is that games don't need to do anything to get a pointer to the raw data, which was probably very nice on the GBA, but perhaps less nice coming into the DS era where NCL, NCG, NSC, NCE, and their runtime formats were introduced with more of a structure.
For ICG, the structure looks like this:
For ISC, the structure looks like:
For the case of ICL files, they're just raw palette data with no footer, same as ACL files.
There are also IOB files, which I presume were an evolution of AOB files and a precursor to NCE files, but I haven't looked into these much yet. Anyways, I hope this would possibly be helpful for anyone who may have also come across these kinds of files.
EDIT: after looking at this game's files myself, it looks like this footer is stripped from the files, so this is all entirely irrelevant to the topic at hand. Ah well.
ACG files start off as raw character graphics data in either 4bpp or 8bpp format, and are immediately followed by attribute data, with 1 byte per tile specifying which palette each tile uses. After the attribute data is the file footer, containing all the metadata about the file. Similarly, ISC files store raw screen data in either text, affine, or affine extended format. The file footer immediately follows this. The file footer for both of these files follows the same structure, being a string of data blocks starting with a 4-byte signature, 4-byte content length in little endian, and 0 or more bytes of data. As a result of storing the file this way, finding the file footer is a bit of a pain since there is no fixed offset from the beginning or the end of the file where it may occur. A nice consequence of this is that games don't need to do anything to get a pointer to the raw data, which was probably very nice on the GBA, but perhaps less nice coming into the DS era where NCL, NCG, NSC, NCE, and their runtime formats were introduced with more of a structure.
For ICG, the structure looks like this:
| Block Signature | Meaning | ||||||
LINK | Which palette file this is linked to relative to this file. The first byte is unused (seems always 1). The second byte is the length of the file name, and the rest is the file name. | ||||||
CMNT | File comment. First byte is ignored (but seems to be 1), followed by a comment length in bytes, followed by the comment string. I presume that this may have allowed for multiple comments in a file, but it doesn't seem like this was used. | ||||||
MODE | Graphics mode. Modes I've seen so far are:
| ||||||
SIZE | The dimensions of character data in tiles. Starts with 16-bit width, then 16-bit height. | ||||||
VER | File version. Only version 1 was used, so this should be IS-ICG01. | ||||||
END | End of file marker, 0 bytes in size. Footer must end in this (but can have padding beyond it). |
For ISC, the structure looks like:
| Block Signature | Meaning |
CLRF | The clear bitmap of this BG. Each bit in this section corresponds to a tile of output. A bit value of 0 means the tile has data, and a 1 means it doesn't. Bits start from the LSB of each byte. |
LINK | Relative path of the ICG file linked to this file. Unlike in ICG files, the LINK section here is not length-prefixed, but null terminated instead. |
CMNT | File comment. Same format as ICG comment string. |
CLRC | Clear character. For all tiles corresponding to a cleared tile (as marked in CLRF), those tiles are filled with this data. |
MODE | The type of background. The first byte is 0 for a text BG, otherwise it is an affine BG. The second byte is read but I can't see how it is used. |
SIZE | Dimensions of screen data. First 2 bytes are the width in tiles, and next 2 bytes are the height in tiles. |
VER | File version. Should be IS-ISC01. |
END | End of file marker, 0 bytes in size. Footer must end with this (can also have other bytes after it). |
For the case of ICL files, they're just raw palette data with no footer, same as ACL files.
There are also IOB files, which I presume were an evolution of AOB files and a precursor to NCE files, but I haven't looked into these much yet. Anyways, I hope this would possibly be helpful for anyone who may have also come across these kinds of files.
EDIT: after looking at this game's files myself, it looks like this footer is stripped from the files, so this is all entirely irrelevant to the topic at hand. Ah well.
Last edited by DailyWeather,
man, thank you for sharing your piece anyways. I really hope this translation project gets finished...eventually
does anyone have the font for the game's graphics? i can see the image folder and what not. we might as well edit the graphics while someone can come in and change the text
Similar threads
- No one is chatting at the moment.
