SZL containers

When an outer .ofs container (RESO) has an entry with type_tag == 'szl' (stored reversed as 'lzs' in the RESO TOC), the payload is an SZL container. SZL is Konami's proprietary compression wrapper: a fixed 16-byte header followed by a standard NDS LZ11 bitstream. Decompressing the LZ11 layer yields standard Nitro graphics resources (NCGR, NCLR, NCER, NANR, NSCR) — typically a complete sprite set packed as a RESO variant=0 sub-container.

The name "SZL" appears to be internal Konami tooling nomenclature. The "1.00" version string in the header and the 'sfo' tag in the outer LZS wrapper both suggest a versioned asset pipeline format that Konami used across multiple DS titles.

Header layout

Total header overhead: 16 bytes before the LZ11 data begins.

Decompressed contents

The decompressed payload is always a standard Nitro RESO variant=0 container holding some combination of:

• NCGR — tile graphics
• NCLR — palette
• NCER — cell/sprite layout
• NANR — animation sequences
• NSCR — background screen maps

These are standard NDS SDK resources that any Nitro-format tool can edit once decompressed.

Where SZL appears in the game

SZL entries are widespread — they appear in OFS containers across many different game systems:

Total: 161 SZL entries successfully decompressed and rendered across the game.

Special case: npcstamp.ofs

The 140 SZL-packed entries in npcstamp.ofs decompress to bare NCGR (tile graphic only, no palette or cell layout). The palette and NCER come from a sibling file — npcstpcmn.lzs (an RESC container with NCER at offset 0xa0 and NCLR at offset 0x110). This is the only known case where SZL entries don't contain a self-sufficient sprite set.

Relationship to the LZS outer wrapper

Don't confuse SZL with LZS. They are different layers:

• LZS (.lzs files) — Konami's outer file-level compression wrapper (16-byte header with "1.00" magic and 'sfo' tag, followed by LZ11). Used on standalone compressed files.
• SZL — appears as RESO entries inside .ofs containers. Same concept (version header + LZ11) but used at the per-entry level within a container rather than at the file level.

Both use the "1.00" version string and LZ11 compression, suggesting they come from the same Konami asset pipeline. The distinction is purely about where they appear: SZL is entry-level (inside a RESO), LZS is file-level (the .lzs extension on disk).

Decoding

Python pseudocode for SZL decompression:

def decode_szl(entry_data):
    assert entry_data[0:4] == b"1.00"  # version check
    # Skip 16-byte header, decompress LZ11 starting at offset 0x10
    assert entry_data[0x10] == 0x11    # LZ11 marker
    decompressed_size = int.from_bytes(entry_data[0x11:0x14], 'little')
    return lz11_decompress(entry_data[0x10:], decompressed_size)

The lz11_decompress function is the same standard NDS LZ11 decoder documented on the LZ11 page. The only SZL-specific work is skipping the 16-byte version header before handing the stream to the LZ11 decoder.