BFFNT (File Format): Difference between revisions

From Wexos's Wiki
Jump to navigationJump to search
Line 326: Line 326:
* [[Tetris 99]]
* [[Tetris 99]]
* [[The Legend of Zelda: Breath of the Wild]] (Nintendo Switch)
* [[The Legend of Zelda: Breath of the Wild]] (Nintendo Switch)
* [[The Legend of Zelda: Echoes of Wisdom]]
* [[The Legend Of Zelda: Link's Awakening]]
* [[The Legend Of Zelda: Link's Awakening]]
* [[Tokyo Mirage Sessions ♯FE Encore]]
* [[Tokyo Mirage Sessions ♯FE Encore]]

Revision as of 21:28, 25 September 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

Version Found in
3.0.0.0
4.1.0.0

Tools

The following tools can handle BFFNT files:

  • (none)