Files
goldeneye-pc-port/port
James Dansereau 643785c2c5 Widescreen FOV Phase 4, D246/D247 overscan crop, D219 rainbow-spark fix
- Widescreen/FOV Phase 4: automatic vertical-FOV scale by window aspect
  ratio (Video.WidescreenAuto, default on), composed before the existing
  manual Video.FovScale multiplier. New symmetric FOV floor (20 deg)
  alongside the existing 160 deg ceiling.
- D247/D246: the game's own TV-overscan safe-area viewport inset (real on
  N64, hidden by CRT overscan, visible as black bars on PC with no crop)
  now gets cropped instead of shown -- gfx_adjust_viewport_or_scissor
  remaps against the actual captured gameplay viewport bounds (vertical)
  plus a measured, resolution-independent 1-logical-unit trim (horizontal)
  instead of the fixed VI canvas size. New Video.SafeAreaCrop toggle,
  default on.
- D219 (rainbow bullet-spark colors), a real 32->64-bit ABI bug:
  bullet_spark_render (glass2.c) read the spark's stored RGBA color via a
  hardcoded raw byte offset instead of the named s_bullet_spark struct
  field -- on 64-bit PC an earlier void* field's widening + alignment
  padding shifts the true offset by 4 bytes, so the read landed in
  unrelated f32 velocity fields instead. Fixed by reading the named
  fields. Also fixed an adjacent UB (a 16-byte Vtx read from a 4-byte
  global) in the same function. This turned out to be the actual root
  cause behind the D252 "lingering particle sprites after an explosion"
  report as well (same render path via objHit and friends) -- closed as
  a duplicate.
- Moved docs/dev/WIDESCREEN-FOV-PLAN.md to docs/dev/notes/ (gitignored
  local notes), matching this project's convention of keeping
  in-progress planning docs out of the tracked tree.

User live-verified all of the above interactively this session.
2026-09-18 01:10:27 -04:00
..
2026-09-01 19:28:59 -04:00

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.