mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-23 15:52:42 +02:00
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
30 lines
1.3 KiB
Markdown
30 lines
1.3 KiB
Markdown
---
|
|
title: Framerate and pacing
|
|
description: 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.c` on 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](porting-notes.md) 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](porting-notes.md) — the timing-related findings (D13,
|
|
D22, D486).*
|