This page documents the binary layout of sprite files found in the Banjo-Kazooie ROM (Nintendo 64). These files contain image data composed of one or more frames, each composed of a series of image chunks.

All multi-byte values are stored in big endian. Unless otherwise stated, all examples use sprite ID `06EB`.

A sprite file is divided into the following sections:

• Header (0x00–0x10)
• Frame Offset Table (0x10–...)
• Frame Data
• Chunk Data (WIP)

The header occupies the first 0x10 bytes of the file and contains basic metadata about the sprite.

The bitfield at `0x0C` may contain rendering options or format hints.

The 32-bit word at offset `0x0C` includes the following layout:

Immediately following the header is the frame offset table. This table contains 32-bit pointers to each frame's data section, relative to the start of the offset table.

Total size of this section = `4 × frameCnt`

Each frame starts with a 20-byte structure:

After the frame header, a sequence of chunk definitions begins.

Each chunk describes a rectangular image section used to draw part of the frame.

There are `chunkCnt` chunk structures per frame, immediately following the frame header.

The sprite rendering system likely interprets pixel data using the following enum:

Format may be deduced from the header `type` field or the bitfield at `0x0C`.

The following C-like structures represent the sprite format as reverse-engineered:

typedef struct {
  u16 frameCnt;
  u16 type;
  u16 unk4;
  u16 unk6;
  u16 unk8;
  u16 unkA;
  struct {
    u32 bit31 : 4;
    u32 bit27 : 3;
    u32 bit24 : 2;
    u32 bit22 : 2;
    u32 pad_bit20 : 21;
  } unkC;
  u32 offsets[];
} BKSprite;
 
typedef struct {
  s16 unk0;
  s16 unk2;
  s16 w;
  s16 h;
  s16 chunkCnt;
  s16 unkA;
  s16 unkC;
  s16 unkE;
  s16 unk10;
  s16 unk12;
} BKSpriteFrame;
 
typedef struct {
  s16 x;
  s16 y;
  s16 w;
  s16 h;
} BKSpriteTextureBlock;

This format is still under investigation. Contributions and corrections welcome.