goldeneye-pc-port/docs/building.md

title, description

title	description
Building	Full build and asset-extraction guide for the GoldenEye 007 PC port, covering Windows (MSYS2) and Linux.

Building the PC port

Stages:

1. Extract assets from your ROM (§2): a one-time step using the decompilation's own toolchain to pull levels, models, textures, fonts and music into assets/. (Only needed to regenerate the committed data files; a plain git clone already has what the PC build compiles.)
2. Build the port (§3): a CMake build compiling the game sources plus the port/ layer into a native executable. Needs no ROM.
3. Generate the PC asset sidecars (§4): two pure-Python converters turn ROM model / stage data into the PC-layout data/pcmodels-* / data/pccg-* files the port loads at runtime. Required to run.

You need a GoldenEye 007 N64 ROM you legally own (.z64, big-endian). See the Requirements table in the README for accepted versions and hashes.

---

1. Dependencies

Port build

The Windows (MSYS2 MINGW64) path is the primary one. The Linux build is compiled by CI on every push and ships in the release bundle (also playtested on Steam Deck hardware); the macOS column is best-effort guidance and has never been built or run there. Expect to fix build breaks yourself on untested platforms.

Need	Windows (MSYS2 MINGW64)	Debian/Ubuntu	macOS (Homebrew)
toolchain	mingw-w64-x86_64-toolchain	build-essential	Xcode CLT / gcc
CMake	mingw-w64-x86_64-cmake	cmake	cmake
SDL2	mingw-w64-x86_64-SDL2	libsdl2-dev	sdl2
zlib	mingw-w64-x86_64-zlib	zlib1g-dev	zlib
OpenGL	(in the toolchain)	libgl1-mesa-dev	(system)
Python 3	mingw-w64-x86_64-python	python3	python3

Asset extraction (decompilation toolchain)

The extraction scripts need binutils-mips-linux-gnu (or an equivalent MIPS binutils), make, git, and python3. They build a small host-compiled tools/extractor and slice blobs straight out of the ROM; no IDO / IRIX toolchain is involved in extraction or in the PC build. (The IDO toolchain is only needed to build the N64 ROM itself, and its proprietary SGI binaries are not distributed here; see SetupGuide.md "Recompile IDO".) On Windows this is easiest under WSL or a Linux VM. Full details and alternatives (Docker) are in SetupGuide.md.

---

2. Extract assets

Put your US ROM at the repository root as baserom.u.z64 (this name is required by the extraction scripts; it is git-ignored and never committed), then:

./scripts/extract_baserom.u.sh

For PAL or JP, additionally place baserom.e.z64 / baserom.j.z64 at the root and run:

./scripts/extract_baserom.u.sh && ./scripts/extract_diff.e.sh   # PAL
./scripts/extract_baserom.u.sh && ./scripts/extract_diff.j.sh   # JP

(US extraction is a prerequisite for the others.)

This populates assets/ with the generated .bin blobs the build needs. See SetupGuide.md for the in-depth build/asset pipeline.

---

3. Build

./build-pc.sh ntsc-final        # or: pal-final / jpn-final

which is equivalent to:

cmake -S . -B build-pc -DROMID=ntsc-final
cmake --build build-pc -j

On Windows, build-pc.sh also locates the MSYS2 MinGW64 toolchain itself (so it works from Git Bash or a non-login shell too, even with another cmake earlier on PATH) and, if native child processes would get an unwritable TMP, re-runs the configure+build under PowerShell with a writable one. If MSYS2 is not installed at C:\msys64, set GE_MSYS2_ROOT (e.g. GE_MSYS2_ROOT='D:\M\msys64'). Re-exec logs: build-pc/ge007-native-reexec-*.log.

For PAL/JP you must first generate that region's ROM-asset symbol file (the US one is committed):

python3 scripts/gen_romassets.py e     # PAL   -> port/src/romassets_e.s
python3 scripts/gen_romassets.py j     # JP    -> port/src/romassets_j.s

The executable lands at build-pc/ge007.x86_64 (.exe on Windows). PAL/JP builds are named ge007.pal-final.x86_64 / ge007.jpn-final.x86_64.

---

4. Generate the PC asset sidecars (required to run)

The port does not read model geometry, stage bg/stan data, or per-level setup data from the raw ROM at runtime; it reads them from PC-layout sidecar files under data/, produced offline by three converters. Without them the game shows the intro logos and then crashes in modelPromoteNodeOffsetsToPointers (finding D179) or on the first level load (missing stage setup).

Put your ROM in data/ first (same file the game runs from):

mkdir -p data
cp /path/to/your/rom.z64 data/ge007.ntsc-final.z64     # or pal-final / jpn-final

Then run all three emit passes for that region, in this order (d88 appends to d69's output):

python3 tools_pc/d43_emit.py ntsc-final          # -> data/pcmodels-ntsc-final/{pcmodels.bin,manifest.csv}  (~1.3 MB)
python3 tools_pc/d69_emit.py ntsc-final          # -> data/pccg-ntsc-final/{pccg.bin,manifest.csv}          (bg + stan)
python3 tools_pc/d88_emit.py ntsc-final --regen  #    appends the 21 per-level Usetup*Z stage-setup files -> ~3.6 MB

PAL / JP note: sidecar generation for these regions is currently broken at the source-data level (finding D258); use an NTSC-U ROM until issue #85 lands.

These are pure-stdlib Python 3 (no MIPS toolchain, independent of the step-2 asset extraction) and read only the ROM plus files already committed to the repo (scripts/filelist.u.csv, assets/obseg/file_resource_table.inc.c, assets/**/ModelFileHeader.inc.c, the bg/stan .inc.c). Output is a deterministic function of the ROM. Re-run after any change to d43_emit.py / d69_emit.py / d88_emit.py or the model/bg converters (d43_*, d69_*, d88_propdefs.py).

The release bundle ships the same converter frozen as prepare-assets/ge007-convert; the game spawns it on first launch when the sidecars are missing, so end users never run it by hand. See the bundled README.md.

data/pcmodels-*/ and data/pccg-*/ are gitignored ROM-derived game data; never commit or redistribute them.

---

5. Run

./build-pc/ge007.x86_64          # run from the repo root

The ROM in data/ (from step 4) and the sidecars are both required at runtime. ge007.ini is written under data/ on first launch.

Useful flags / env

-level_NN	boot straight into a solo level (e.g. -level_09 = Bunker 1)
GE_PCDUMP="first-last:step"	dump rendered frames as PPM (debugging)

More diagnostic switches are cataloged in dev/GE-ENV-PROBES.md.