File Formats

The game's files are layered. A single .lzs file is usually a compressed wrapper around a container, and the container holds several smaller files inside it. Each of those smaller files has its own format. So before you can look at, say, a tile sheet inside the title screen pack, you have to unwrap two or three layers.

These pages cover each layer in order — the outer wrappers first, then the containers, then the actual asset formats inside them.

The wrapping order

Most asset files are wrapped like this:

.lzs file
  └─ LZS wrapper (16 byte header)
      └─ LZ11 compressed stream
          └─ RESO container
              ├─ tile sheet (NCGR)
              ├─ palette (NCLR)
              ├─ sprite definition (NCER)
              └─ background tilemap (NSCR)

A .ofs file skips the LZS wrapper and the compression — it's just a RESO container directly. A .bin file may be raw binary (no wrapper), or BLZ-compressed code (the main ARM9 binary), or one of several smaller bespoke formats.

ROM file structure

Where everything lives in the NDS ROM — the six root files, 180 overlays, and 30+ data subdirectories covering dialog, models, scripts, items, maps, and more.

RESO containers

The main container format. A simple table of contents pointing at chunks of data. Two header variants and a list of type tags for the chunks.

LZS / LZ11 compression

The compression wrapper Nintendo uses on most assets. About 70 percent of files in the game are LZ11-compressed.

SZL containers

Konami's compressed sprite wrapper — a 16-byte header plus LZ11, yielding standard Nitro graphics inside. Found in 161 entries across clothing, NPC, stamp, UCC, and trophy containers.

BLZ & the plaintext-ARM9 trick

The backward-LZ compression Nintendo uses for executable ARM9 code, plus the CompressedStaticEnd patch that lets the toolchain edit ARM9 strings as plaintext.

Nintendo Nitro graphics formats

NCGR, NCLR, NCER, NSCR, NANR. The five Nintendo formats that hold all the actual image data. Standard across most DS games.

Konami's custom extensions

Tags that aren't standard Nintendo. tad holds widget tables; nib, rnan, sfo wrap other kinds of binary data inside RESO containers.

RESC v3.11 containers

A newer container with named entries and a 48-byte TOC stride. Holds the cooking recipe database; round-trip-safe writer shipped in v2.4 prep.

The `recipe/` folder

Three files behind cooking: a RESC v3.11 recipe database, a pointer-deduplicated narration table, and a binary item_id lookup — all wearing the same SZL + LZ11 outer envelope. All three writers ship in v2.4.

UI containers (text audit)

The 16 player-facing UI container files (bulletin board, mail, locker, music select, etc.) plus the inputstr/ directory — confirmed to carry zero translatable text. They are TAD/RESC graphics archives; their text comes from msg*.ofs message files instead.

The Tinke / Nintendo language tax

Almost every format here has its magic bytes stored backwards. The RESO file you'd expect to start with RESO does start with RESO, but the entry tags inside it are reversed — rgcn in the file means the entry is an NCGR, rlcn means NCLR, and so on. This is just little-endian byte order showing through: the engine reads a 4-character tag as a 32-bit integer, so the bytes appear reversed when you stare at the file in a hex editor.