BFFNT (File Format): Difference between revisions
(Imported from avsys wiki) |
|||
Line 304: | Line 304: | ||
* [[PAC-MAN 99]] | * [[PAC-MAN 99]] | ||
* [[Paper Mario: The Origami King]] | * [[Paper Mario: The Origami King]] | ||
* [[Paper Mario: The Thousand-Year Door]] (Nintendo Switch) | |||
* [[Pikmin 3 Deluxe]] | * [[Pikmin 3 Deluxe]] | ||
* [[Pokémon Legends: Arceus]] | * [[Pokémon Legends: Arceus]] |
Revision as of 14:52, 23 May 2024
BFFNT (Binary caFe FoNT) is a font file format used on Wii U and the Nintendo Switch.
File Format
Header
The file starts with a header which has the following structure:
Offset | Type | Description |
---|---|---|
0x00 | Char[4] | File magic. Always FFNT in ASCII. |
0x04 | UInt16 | Byte-order-mark. FE FF for big endian, FF FE for little endian. |
0x06 | UInt16 | Size of this header in bytes. |
0x08 | UInt32 | Version number. |
0x0C | UInt32 | Size of the file in bytes. |
0x10 | UInt16 | Number of sections stored in the file. There may be multiple code maps and character widths inside a file. |
0x12 | UInt16 | Padding. |
Font Information
The FINF (Font INFormation) section stores general information about the font, and it places directly after the header. It has the following structure:
Offset | Type | Description |
---|---|---|
0x00 | Char[4] | Section magic. Always FINF in ASCII. |
0x04 | UInt32 | Size of this section in bytes. |
0x08 | Byte | Font type. 0 = Glyph, 1 = Texture, 2 = Packed texture. |
0x09 | Byte | Font height. |
0x0A | Byte | Font width. |
0x0B | Byte | Ascent. |
0x0C | Int16 | Line feed. |
0x0E | UInt16 | Alter character index. |
0x10 | SByte | Default left width. |
0x11 | Byte | Default glyph width. |
0x12 | Byte | Default character width. |
0x13 | Byte | Character code. 1 = Unicode, 2 = Shift JIS, 3 = CP1252 |
0x14 | UInt32 | Texture glyph offset. Relative to -8. |
0x18 | UInt32 | Code map offset. Relative to -8. |
0x1C | UInt32 | Character width offset. Relative to -8. |
Texture Glyph
The TGLP (Texture GLyPh) section stores the textures used in the font. On Wii U, the image data is stored directly, and on the Nintendo Switch the images are stored into a BNTX file, embedded inside the font.
Offset | Type | Description |
---|---|---|
0x00 | Char[4] | Section magic. Always TGLP in ASCII. |
0x04 | UInt32 | Size of this section in bytes. |
0x08 | Byte | Cell width. |
0x09 | Byte | Cell height. |
0x0A | Byte | Number of image sheets. For Nintendo Switch, this is the number of images inside the BNTX file. |
0x0B | Byte | Maximum character width. |
0x0C | UInt32 | Size of one image sheet in bytes. For Nintendo Switch, this seems to be size of BNTX divided by number of images. |
0x10 | Int16 | Baseline position. |
0x12 | UInt16 | Image format, see below. Bit 0x8000 means it's compressed, but it's currently not used. For Nintendo Switch, bit 0x4000 means the tile mode is linear, which means the image data is not swizzled. |
0x14 | UInt16 | Number of rows. |
0x16 | UInt16 | Number of lines. |
0x18 | UInt16 | Image sheet width. Width of the images in pixels. |
0x1A | UInt16 | Image sheet height. Height of the images in pixels. |
0x1C | UInt32 | Image data offset, relative to the start of this file. For Wii U, this points directly to the first image. For Nintendo Switch, this points to the embedded BNTX file. |
Image Formats
- Wii U
The following image formats are supported on Wii U:
ID | Type | Color Space | Bits Per Pixel (BPP) |
---|---|---|---|
0x00 | RGBA8 | UNORM | 32 |
0x01 | RGB8 | UNORM | 24 |
0x02 | RGB5A1 | UNORM | 16 |
0x03 | RGB565 | UNORM | 16 |
0x04 | RGBA4 | UNORM | 16 |
0x05 | LA8 | UNORM | 16 |
0x06 | LA4 | UNORM | 8 |
0x07 | A4 | UNORM | 4 |
0x08 | A8 | UNORM | 8 |
0x09 | BC1 | UNORM | 4 |
0x0A | BC2 | UNORM | 8 |
0x0B | BC3 | UNORM | 8 |
0x0C | BC4 | UNORM | 4 |
0x0D | BC5 | UNORM | 8 |
0x0E | RGBA8 | SRGB | 32 |
0x0F | BC1 | SRGB | 4 |
0x10 | BC2 | SRGB | 8 |
0x11 | BC3 | SRGB | 8 |
- Switch
Nintendo Switch supports the same formats as Wii U but adds support for the following formats:
ID | Type | Color Space | Bits Per Pixel (BPP) |
---|---|---|---|
0x12 | BC7 | UNORM | 8 |
0x13 | BC7 | SRGB | 8 |
Code Map
The CMAP (Code MAP) section maps character codes to character widths. The section starts with the following structure:
Offset | Type | Description | |
---|---|---|---|
0x00 | Char[4] | Section magic. Always CMAP in ASCII. | |
0x04 | UInt32 | Size of this section in bytes. | |
If version ≥ 3.0.0.0 | |||
0x08 | UInt32 | Character code begin. Always 0 for scan, because then this field is unused. | |
0x0C | UInt32 | Character code end. Always 0xFFFFFFFFF for scan, because then this field is unused. | |
0x10 | UInt16 | Mapping method. 0 = Direct, 1 = Table, 2 = Scan | |
0x12 | UInt16 | Padding. | |
0x14 | UInt32 | Offset to the next code map structure, releative to -8. 0 if there is no following section. | |
Else | |||
0x08 | UInt16 | Character code begin (B). Always 0 for scan, because then this field is unused. | |
0x0A | UInt16 | Character code end (E). Always 0xFFFF for scan, because then this field is unused. | |
0x0C | UInt16 | Mapping method. 0 = Direct, 1 = Table, 2 = Scan | |
0x0E | UInt16 | Padding. | |
0x10 | UInt32 | Offset to the next code map structure, releative to -8. 0 if there is no following section. |
What data follows depend on the mapping method.
- Direct
The direct method maps multiple character codes to multiple character width entries. The following data is stored:
Offset | Type | Description |
---|---|---|
0x00 | UInt16 | Character width entry index. Index of the first entry which maps to the first character code B. This method uses E - B + 1 character width entries. |
- Table
The table method also maps multiple character codes to multiple character width entries. The following data is stored:
Offset | Type | Description |
---|---|---|
0x00 | UInt16[E - B + 1] | Character width entry indices. Each index corresponds to one character code, starting at B. |
- Scan
The scan method maps multiple character codes to mutlple character width entries. This structure does not use B and E. The following data is stored.
Offset | Type | Description |
---|---|---|
0x00 | UInt16 | Number of scan entries. |
Each entry has the following structure:
Offset | Type | Description |
---|---|---|
0x00 | UInt16 | Character code. |
0x02 | UInt16 | Character width entry index. |
Character Width
The CWDH (Character WiDtH) section controls how the characters are stored in the images. The section starts with the following header:
Offset | Type | Description |
---|---|---|
0x00 | Char[4] | Section magic. Always CWDH in ASCII. |
0x04 | UInt32 | Size of this section in bytes. |
0x08 | UInt16 | Global index of the first width entry (B). |
0x0A | UInt16 | Global index of the last width entry (E). |
0x0C | UInt32 | Offset to the next character width structure, releative to -8. 0 if there is no following section. |
Width Entry
Width entries follow directly after the header. The amount can be calculated with: E - B + 1. There will always be at least one entry stored. Each entry has the following structure:
Offset | Type | Description |
---|---|---|
0x00 | SByte | Left width. The width of the character's left space. |
0x01 | Byte | Glyph width of the character. |
0x02 | Byte | Width of the character. |
Version List
Tools
The following tools can handle BFFNT files:
- (none)