0 Fork 1

mirror of https://github.com/jkdansereau/goldeneye-pc-port.git synced 2026-10-24 00:02:45 +02:00

Files

T

James Dansereau f55a89515f D219: root cause found -- fire particle texture data itself is R/B-swapped, not a rendering bug (#71 )

Live-tested against 4 real user playtests (not scripted) tonight, each
confirming purple/blue explosions still reproduce on current main:

1. G_LIGHTING hypothesis (previous session's lead) RULED OUT: extended the
   D172 probe to flag lit particle draws uncapped (the original 40-hit cap,
   sized for a short scripted repro, silently went dark after ~40 ordinary
   bullet-impact particles well before any real explosion -- masking the
   result, not confirming it). Fixed with an always-on periodic counter.
   Result: 5000+ particle draws logged across a real playtest with
   explosions triggered, 100% LIGHTING=off, 0 suspect hits.

2. Texture-cache-collision hypothesis RULED OUT: extended the same probe to
   log the actual bound TEXEL1 address/GL-texture-id/byte-count. 7 distinct,
   internally-consistent 448-byte (16x14 RGBA16) textures observed -- no
   aliasing, no stale-slot signature.

3. ROOT CAUSE: used the existing GE_TEXDUMP feature (extended to exempt
   16x14 RGBA images from its own 400-image cap, same masking problem as
   above) to dump all 15 IMAGE_FIRE_0..14 particle textures as PPM during a
   live playtest with confirmed-purple explosions. Every single one decodes
   blue/purple-dominant; swapping the decoded R and B channels turns all 15
   into a plausible warm fire palette, consistently. This is NOT a bug in
   the shared RGBA16 decoder (port/fast3d/gfx_pc.cpp import_texture_rgba16)
   -- that function is proven correct by every other RGBA16 texture in the
   game rendering fine, and the general C-array byte-order normalization
   already runs upstream of it. The wrongness is in the decoded bytes
   themselves: either the Globalimagetable entries for these 15 image ids
   resolve to the wrong ROM offset, or these assets use a sub-format the
   shared decoder doesn't special-case. Do NOT blanket-swap R/B in the
   shared decoder -- it would break every correctly-rendering RGBA16
   texture in the game.

Also fixes a mistake made mid-session: a follow-up raw-byte-dump probe
(GE_TEXRAW) initially keyed its own cap-exemption on the wrong field
(gsDPSetTileSize's logical 56x56 wrap size instead of the real 16x14 pixel
content), so it never matched and burned a live-playtest cycle for nothing.
Fixed to key on the real signature: a 448-byte load (16*14*2, RGBA16).

Diagnostic infra left in tree, env-gated and inert by default:
GE_D172=1 (uncapped lit-case + periodic counter in gfx_sp_tri1),
GE_TEXDUMP=1 (16x14-exempt-from-cap fire dumper in gfx_opengl_upload_texture),
GE_TEXRAW=1 (fixed 448-byte-exempt raw dump in the texture import path).

2026-09-12 17:06:59 -04:00

fast3d

D219: root cause found -- fire particle texture data itself is R/B-swapped, not a rendering bug (#71 )

2026-09-12 17:06:59 -04:00

include

docs(dev): D202 M-71 by-ear PASS + close-ready; new D205 wrong/extra SFX indices (bank exonerated); [VOL]/[DISTVOL] probes

2026-09-07 14:18:39 -04:00

shim

linux-runtime: declare getenv()/realloc() for the strict-host build

2026-09-02 23:03:46 -04:00

src

QoL: Game.NoHitFlash toggle (D232) (#58 )

2026-09-12 09:20:13 -04:00

README.md

Prepare for public release

2026-09-01 19:28:59 -04:00

README.md

GoldenEye 007 — PC port layer

This directory contains the PC port layer: the code that lets the (unmodified) GoldenEye game sources run on a modern host instead of N64 hardware.

It mirrors the layout of the Perfect Dark PC port, which ports the same Rare engine family. See docs/internals.md (repo root) for the full research write-up and phased plan.

Layout

port/
├── fast3d/            # Software RSP: interprets GBI display lists -> OpenGL
│   ├── gfx_pc.cpp     #   RSP interpreter (matrices, lights, tris, fog)
│   ├── gfx_opengl.cpp #   OpenGL rendering backend (shaders, textures, zbuf)
│   ├── gfx_sdl2.cpp   #   SDL2 window-manager backend
│   ├── gfx_cc.cpp     #   color-combiner -> GLSL shader compiler
│   └── ...
├── include/           # port-facing headers
│   ├── audio.h  config.h  fs.h  input.h  mixer.h
│   ├── platform.h  romdata.h  system.h  video.h  utils.h
│   └── versioninfo.h.in
└── src/
    ├── main.c         # PC entry point (replaces boot.s / init())
    ├── libultra.c     # shims for the libultra OS API
    ├── video.c        # SDL2 window + GL context + frame pacing
    ├── audio.c        # SDL audio device, buffer queueing
    ├── mixer.c        # audio mixing
    ├── input.c        # SDL2 keyboard/mouse/gamepad -> N64 controller structs
    ├── fs.c           # filesystem abstraction over the ROM + data dir
    ├── romdata.c      # loads the .z64 ROM from disk, sets up segments
    ├── config.c       # INI config (ge007.ini)
    ├── system.c       # platform primitives (time, logging, paths)
    ├── crash.c        # crash handler / stack traces
    ├── gesched.c      # replacement RCP scheduler that drives the software RSP
    └── utils.c

How it works (short version)

The R4300 game code (src/game, src) is compiled unmodified.
The RSP is emulated in software (fast3d/): it interprets the Gfx display list the game builds and emits OpenGL calls, bypassing the RDP.
The RCP scheduler (gesched.c) replaces src/sched.c's hardware task submission: instead of writing RSP registers it calls gfx_run().
libultra OS functions are shimmed in libultra.c (single-threaded, host clock, VI/PI/SI/AI mapped onto the video/audio/fs/input layers).
Saves (Memory Pak / EEPROM) are backed by files in the data dir.

GE-specific RSP work

The PD fast3d already handles G_TRI4 (GE's 4-triangle command). The new work for GE is:

G_SETTEX — GE's custom texture-bank command (include/gbi_extension.h, gsSPUseTexture). Must be added to the RSP interpreter + GL backend.
Verify GE's custom color-combiner modes (G_CC_*FADE*) and render mode (G_RM_CUSTOM_AA_ZB_XLU_SURF) produce correct GLSL / GL state.

Use rsp/graphics/gmain.s (the real GE RSP ucode) as the ground truth for the exact command encodings.

Status

Scaffolding only. The files in src/ and fast3d/ are stubs that define the interfaces and mark the work to be done. The actual implementation is brought in phase by phase (see docs/internals.md §8), largely by adapting the PD port's port/ layer.