Family A of the M-36 triage (Surface "grey static" D176b, file-select interlacing D182-2). The assigned hypothesis — import_texture_* shear when line_size_bytes != full_image_line_size_bytes — is DISPROVEN for the Surface repro: - Only gfx_dp_load_tile produces a strided load; GE loads every texture via gDPLoadBlock (tex.c texWriteLoadToTmem*), which sets line == full. Measured: 0/64 GE_DTEX + 0/166 GE_TEXDUMP imports strided on -level_36; 0 in the front end either. - Independent offline pitch scan (new GE_TEXRAW dump) shows the importers pick exactly the pitch the source is stored at. The Surface cliff texture is a 32x32 IA8 whose ROM bytes are genuinely a noise field — decoded faithfully, tiled ~1 texel/px. D176(b) is likely a tiling-density / UV / shift-LOD issue (RC3/D167 family) or a wrong-texture bind, not a decode bug. Full evidence: findings.md D183. D176(b)/D182(2) stay OPEN. - Re-confirmed D159's texSwapAltRowBytes no-op is correct (re-applying it makes the dumps worse). Shipped anyway (golden-safe, reversible): - import_texture() compacts strided rows into a contiguous buffer before the format dispatch, so every importer sees line == full — the behaviour the seven SUPPORT_CHECK(full == line) asserts only assert (and assert compiles out under NDEBUG). Provably inert when full == line (all current loads). GE_TEXPITCH=0 restores the old flat read. - GE_DTEX gains line=/full=/STRIDED markers; GE_TEXRAW=1 dumps raw importer-input bytes for offline decode-vs-source analysis. Verified: build 240/240; -level_09 framediff 3/3; GE_STARTMENU=10 briefing crash-free, renders. Investigation: subagent (worktree). Claude-Session: https://claude.ai/code/session_01GULf6knbsqfsnW39tMr9WT
fast3d — software RSP
A C++ interpreter that consumes the Gfx display list the game builds each
frame and emits OpenGL calls, replacing the Nintendo 64's Reality Signal
Processor and Reality Display Processor.
Origin and license
This code is adapted from the Perfect Dark PC
port (port/fast3d/), which in
turn is the Ship of Harkinian /
libultraship fast3d, itself descended from
sm64-port.
LICENSE.txt in this directory (MIT, © 2020 Emill, MaikelChan) covers that
lineage. glad/ is generated by glad
(© David Herberth, MIT). GoldenEye-specific changes in this directory are
under the repository's top-level MIT license.
Files
| File | Role |
|---|---|
gfx_pc.cpp |
the RSP interpreter — matrices, lights, fog, G_TRI1/G_TRI4, vtx |
gfx_opengl.cpp |
OpenGL backend — shaders, textures, z-buffer, framebuffers |
gfx_cc.cpp |
color-combiner equation -> GLSL shader |
gfx_sdl2.cpp |
SDL2 window-manager backend |
gfx_api.h |
public API (gfx_init / gfx_run / gfx_start_frame / ...) |
gbiex.h |
GoldenEye custom GBI command definitions |
glad/ |
OpenGL loader |
GoldenEye-specific work
The PD fast3d already handles G_TRI4 (GoldenEye uses it too). The GE additions
are the custom color-combiner / render modes and the handling of GE's GBI
extension commands. rsp/graphics/gmain.s (GE's real RSP microcode, in the
repo root) is the ground truth for the exact command encodings.