Files
goldeneye-pc-port/port/fast3d
James Dansereau 4b71435d73 port: D183 — fast3d source-pitch de-stride + texture diagnostics (M-36 Family A)
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
2026-09-02 11:00:11 -04:00
..
2026-09-01 19:28:59 -04:00
2026-09-01 19:28:59 -04:00

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.