Asset type dispatcher Confirmed

At a glance

Magic

none - the type byte is the top 8 bits of a u32 packed with the 24-bit size

Where on disc

every DATA_FIELD chunk header and every asset descriptor carries one

Dispatcher

FUN_8001F05C in SCUS_942.54

Parser

crates/container-formats/src/lib.rs::AssetType

Confidence

Confirmed - the dispatcher is dumped in full, and the developers' own malloc-error strings name each type (how we know)

Used by

asset loader, LZS decoder (the compressed path)

What a type byte is

Legaia's containers do not label their contents with a per-format magic word the way a PNG or a ZIP does. The container that carries an asset - a streaming chunk or a descriptor table - stores a one-byte code next to its size, and the code alone decides what happens next: which buffer is allocated, whether the bytes are copied or LZS-decompressed, and which subsystem is told "your data has arrived". The code space is a dozen values, fixed in the executable, so the same table serves every scene, battle and menu on the disc.

Calling convention

result = FUN_8001f05c(byte *src_data, u32 type_and_size, int param3, int copy_only);

The second argument is the same little-endian word a DATA_FIELD chunk header stores, so in memory it reads size first, type last:

• type_and_size packs type in the high 8 bits, size in the low 24 bits.
• copy_only != 0 → the asset is uncompressed and is copied into its buffer.
• copy_only == 0 → the asset is LZS-compressed and goes through the LZS decoder, the game's dictionary decompressor.

Type table

The full type space, with the bit each type contributes to the return value. The names are the developers' own: each type has a per-type malloc-error string in the executable.

Return-value bitfield

Every return is a small bitfield - one bit per data-bearing type, and type << 8 for the markers. Both callers (the streaming walker and the descriptor walker) OR every return into one accumulator, so the result summarises what a whole stream contained:

Why FLAG types exist

The FLAG cases let the dispatcher accept chunks whose type byte falls outside the data-bearing range without aborting the streaming walk. The walker still skips the data bytes (advance = 4 + (size & ~3)), but the dispatcher never reads them. FLAG chunks are stream-level out-of-band markers: any caller that looks at the returned bitfield can detect "this stream contained a 0x14-typed marker" without the marker carrying a parsed asset. Where the markers are consumed is open. It is not the bytes past the streaming terminator: the DATA_FIELD trailer is last-sector fill that nothing reads.

In the port

legaia_container_formats::AssetType mirrors the table one variant per type byte, with Flag(u8) for the three markers and Unknown(u8) for everything else - the same silent no-op the retail dispatcher performs (below).

Who calls the dispatcher

Three call sites exist, and only one is visible from the executable's static call graph. The others are reached from overlays - chunks of MIPS code the game loads into RAM on demand, where most game logic lives. Zero static callers does not mean dead.

What an unrecognised type byte does

242 of the 256 possible bytes are unrecognised: the seven in-range gaps 0x0C, 0x0D, 0x0E, 0x10–0x13, and everything from 0x15 up. The range check sltiu $v0, $v1, 0x15 sends the high ones to 0x8001F660, and the jump table sends the seven gaps to exactly the same address.

That address is not a default handler — it is the function's return tail. The accumulator register is zeroed on entry and nothing on an unrecognised path writes it, so the call returns 0 having done nothing: no allocation, no decompression, no copy, no registration, and no error raised. It is a silent no-op. A reference sweep of the jump table's own address range across 84 images finds one hit, the instruction that indexes it, so nothing installs a handler into the empty slots at runtime.

How we know

Source of record: docs/formats/asset-type.md.

See also