Why
RT64's F3D_Gold RSP-emulation path keeps hitting an unexplained address-corruption bug (real game vertices/textures resolve to DL-stream bytes). Three candidate mechanisms have now been falsified (segment table, level-load crash, OOB RDRAM — see #2 and docs/INVESTIGATION.md). Visible geometry via RT64 is weeks-out and uncertain.
Proposal
Perfect Dark uses the same Rare microcode lineage (F3D_PD) and its shipping arm64 macOS binary is a confirmed Fast3D-on-GL GBI interpreter (verified strings in a local pd.arm64). Fast3D consumes the already-emitted Gfx[] display-list stream and deletes the entire RSP-emulation addressing bug class RT64 is stuck on.
Plan:
- Vendor
fast3d/{gfx_pc,gfx_opengl,gfx_cc,...} from fgsfdsfgs/perfect_dark@port.
- Stand it up behind
GE_USE_FAST3D=1 (leave RT64 intact), wired at the submit_rsp_task / OSTask->t.data_ptr boundary, populating seg_addr from GoldenEye's gSPSegment.
- Handle GE's texture-triangle opcodes (0xCA/0xCB/0xCE).
Smallest milestone
One -level_10 frame routed through gfx_run_dl() producing >250k non-zero pixels in the existing PPM-dump metric (vs RT64's current zero-content), cross-checked against the live PD reference renderer.
Estimate
~1–2 weeks of focused integration; higher risk-adjusted payoff than incrementally fixing RT64's F3D_Gold path.
Why
RT64's F3D_Gold RSP-emulation path keeps hitting an unexplained address-corruption bug (real game vertices/textures resolve to DL-stream bytes). Three candidate mechanisms have now been falsified (segment table, level-load crash, OOB RDRAM — see #2 and
docs/INVESTIGATION.md). Visible geometry via RT64 is weeks-out and uncertain.Proposal
Perfect Dark uses the same Rare microcode lineage (F3D_PD) and its shipping arm64 macOS binary is a confirmed Fast3D-on-GL GBI interpreter (verified strings in a local
pd.arm64). Fast3D consumes the already-emittedGfx[]display-list stream and deletes the entire RSP-emulation addressing bug class RT64 is stuck on.Plan:
fast3d/{gfx_pc,gfx_opengl,gfx_cc,...}fromfgsfdsfgs/perfect_dark@port.GE_USE_FAST3D=1(leave RT64 intact), wired at thesubmit_rsp_task/OSTask->t.data_ptrboundary, populatingseg_addrfrom GoldenEye'sgSPSegment.Smallest milestone
One
-level_10frame routed throughgfx_run_dl()producing >250k non-zero pixels in the existing PPM-dump metric (vs RT64's current zero-content), cross-checked against the live PD reference renderer.Estimate
~1–2 weeks of focused integration; higher risk-adjusted payoff than incrementally fixing RT64's F3D_Gold path.