forked from Ports/goldeneye-pc-port
James Dansereau
d7b9371afb
Public-copy language pass, homepage restructure and Documentation rename, 404 page, dead-anchor and permalink fixes, release-gate sign-off, and the pre-release review fixes of the 2026-10-05 batch (probe-doc drift, build-path hygiene, verify.sh and capture safety). Refs: D533 D534
1.5 KiB
1.5 KiB
title, description, date, modified_time
| title | description | date | modified_time |
|---|---|---|---|
| The asset pipeline | How the GoldenEye 007 PC port turns N64 ROM assets into the model and graphics files it loads at runtime. | 2026-10-05 | 2026-10-05 |
The asset pipeline
The N64 stored the game's assets (models, textures, fonts, level and cutscene data) inside the ROM in on-hardware formats a PC can't use directly. The port converts them into two "sidecar" files it loads at runtime:
pcmodels— the 3D models (a PC layout of the N64's RZ model format).pccg— the graphics: textures, fonts and the rest of the ROM data.
Each is a single concatenated image plus a small manifest.csv (name, offset,
size) that the loader reads — port/src/pcmodels.c and port/src/pccg.c.
Where they come from. Two paths produce the same files:
- A downloaded build generates them from your ROM on first start, into
data/pcmodels-<region>/anddata/pccg-<region>/next to the executable. Delete them at any time — they are made again on the next start. - Building from source runs the offline Python converters in
tools_pc/to produce the same files (see the Building guide, §4).
This is one of the deliberate differences from the Perfect Dark port, which fixes up the N64 asset formats at load time: GoldenEye's serialized formats are converted offline instead.
More: building §2 and §4; the loaders are
port/src/pcmodels.c and port/src/pccg.c.