James Dansereau
425237f93f
GE's texLoadFromGdl picks a handler per G_NOOP texture reference from w0 & 7. TEXTURETYPE_LOD/MIPMAP (texHandleType0/Type2) issue ONE load block at TMEM 0, so tiles 0..n are LOD levels of that one image. TEXTURETYPE_DETAIL (texHandleType1, src/game/tex.c) issues TWO: the detail texture at TMEM 0 and the real base image at TMEM texGetSizeInBytes(detail,0) on tiles 1+. gfx_lod_tile_offset folded every G_TL_LOD draw to tile 0 (D107 -- correct for the first two, wrong for DETAIL), so the port drew the detail texture and never imported the base image at all. All four Surface 1 treeline cards (tex1198-tex1201, RGBA5551 64x17 cut-outs) are DETAIL bindings sharing one detail texture, tex2465: an opaque 32x32 IA8 noise tile. That is the same texture D267/D276 measured at 1023/1024 texels opaque and called the mystery "noise painter" -- hence 20+ passes chasing decode, alpha, mip and geometry theories for what was a binding bug. Fix (port layer only): under G_TL_LOD, if tile fi+1 differs from tile fi in BOTH TMEM address and fmt/siz, sample tile 1. Asymmetric on purpose -- LOD levels of one image always share a format, so a mip chain can never trip it, and a detail pair that happened to share a format just keeps the old behaviour. Config Video.DetailBaseTile, default on. Verified: Surface 1 idle spawn goes from an opaque tiled noise wall to discrete snow-covered pines with ground/snow unchanged; Surface 2 shows a discrete night treeline; Depot renders clean; bunker1 golden framediff is bit-identical with the fix on and off. Offline scan of every level's bg: DETAIL bindings exist only in sevx (84), depo (39), sevb (4), sev (4), so every other level is provably untouched. User play-test confirmed. Also refuted and removed pass 25's fix direction: cut-out mip suppression changed nothing, and its alpha census showed the wall is painted by a fully opaque texture -- retiring the mip / 1-bit-alpha / XLU-smear branch. The GE_D236P25 probe is gone with it. tools_pc/gen_env_probes.py: stop counting a "GE_FOO[" log-line TAG in the doc as a documented env var. GE_TEXDUMP_ADDR prints "GE_TEXA[...]", which is not the name of any getenv(), so the check reported a permanent phantom GONE. Generalised as docs/porting-notes.md D12; full trail in findings.md D236 pass 26. Carries the pending D75/M-197 sidecar-converter fix and the env-gated D236/D75 probes, which the doc gates require to land alongside their rows.
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.