forked from Ports/goldeneye-pc-port
James Dansereau
452fa1025a
Linux reference-frame set for all 21 levels and the cross-platform golden rule (D521); golden tooling made non-destructive (D524); the gate pins a canonical in-tree save (D529) and the PRNG seed (D532); the capture tool's per-level re-pin bug fixed and the Linux set re-captured under the canonical save (D530, D531); no-arg verify.sh exits non-zero. README and docs visual/consolidation passes; the 15 MB preview gif replaced by stills. Refs: D521 D523 D524 D525 D526 D527 D528 D529 D530 D531 D532
1.3 KiB
1.3 KiB
title, description
| title | description |
|---|---|
| Framerate and pacing | How the GoldenEye 007 PC port holds a steady 60 fps and keeps per-frame game timing correct on a fast CPU. |
Framerate and pacing
The port targets a steady 60 fps with VSync and an optional 30/60 frame cap, including on low-end GPUs.
The N64's game code assumed a 60 Hz vertical-interrupt tick — it ran a few ticks per displayed frame. On a PC the CPU is far faster, so left alone the game logic would race ahead. The port handles this in two places:
- Frame pacing happens in
port/src/video.con the render thread (the software RSP thread), which paces the frame and does the swap and FPS accounting. - Per-frame counters in the game are gated with
portN64FrameStep()so they advance at the display rate, not the CPU rate. Getting this wrong is a recurring class of subtle timing bug (a counter that ticks too fast, a stall that isn't real) — the porting notes track these (for example D13, D22 and D486).
On very weak integrated GPUs (Atom/Celeron class) the first launch writes
lighter values for draw distance, LOD distance and anti-aliasing into
ge007.ini so the game still holds 60 fps.
More: porting notes — the timing-related findings (D13, D22, D486).