Performance & verification¶
Status: Current work · Reviewed 8 September 2026
What was causing uneven motion¶
The camera used the 30 Hz predicted simulation position directly. A high render rate repeated the same position between simulation ticks. The renderer also used a separate 60 Hz timer on Retina displays, disabled anti-aliasing there and adjusted resolution during play. Together these could produce uneven movement and changing clarity despite a high FPS average.
Remote entities could extrapolate from the oldest retained snapshot when a new packet was late. Animation state could also be shown before its timestamp. Moving shadow focus was snapped along world axes instead of the shadow camera's texel grid. Nearby point lights switched abruptly.
Changes in this pass¶
- Preview the next collision-resolved movement tick and sample between endpoints for rendering. Simulation/input rate stays at 30 Hz; mouse look stays immediate.
- Follow browser display cadence, retain a bounded fixed pixel budget and enable anti-aliasing. No automatic resolution pumping or motion blur. Saved user graphics choices remain respected; new defaults use 100% scale.
- Bound late-packet extrapolation, interpolate speed, apply animation states at their timestamps and keep the interpolation clock monotonic.
- Snap shadow focus in light space. Keep four point-light slots and fade before changing their source.
- Reuse a bounded pool of lightning geometry/materials; prewarm its shaders during loading. Stable geometry and quick fades preserve the blue-white bolt without regenerating tubes for each cast.
- Show rolling 95th-percentile frame time, 1% low FPS, hitch count and actual resolution in F3. The window holds the most recent 360 frames.
Verification scope¶
Automated movement tests cover 60, 120, 200 and 240 Hz sampling with a 30 Hz simulation, collision, non-mutating prediction, late packets, animation timestamps, shadow texels, frame statistics and repeated lightning allocation. Existing character and environment tests remain part of verification.
Browser measurements are local Chrome automation at its available 60 Hz cadence. They do not prove a physical ProMotion panel delivers 120 or 200 Hz. The production build was exercised at 1280 × 633, device pixel ratio 1, render scale 100%, against an isolated copy of the zone and quest data.
| Capture | Frames | Median / p95 / p99 | Worst frame | Result |
|---|---|---|---|---|
| Straight movement on a collider-checked road | 240 | 16.7 / 17.2 / 17.3 ms | 17.7 ms | 0 stationary or oversized steps in the 210 steady-state samples |
| Fast turns, live casts and staged repeated effects | 600 | 16.7 / 17.1 / 17.3 ms | 19.6 ms | 0 frames above 33 ms; 0 failed shaders |
The steady-state movement sample excludes the first 30 acceleration frames. The casting capture deliberately adds repeated visual bolts/rifts alongside normal spell input; it is an effects stress sample, not a claim that every staged effect was an authoritative combat hit. Clean browser sessions reported no runtime errors. Type checking, the production build, all 21 regression tests, and the strict wiki build passed.
These are short automated captures, not a five-minute hardware soak. High-rate movement math is tested at 60, 120, 200 and 240 Hz, but actual ProMotion presentation still needs the user's normal display/browser check. Raw verification record.
M4 Pro acceptance target¶
Proposed hardware check: the user's normal browser and display settings, plugged in, documented viewport/render resolution, a warm game, repeated fast turns, village-to-camp traversal and combat for five minutes. At 120 Hz aim for a 95th-percentile frame interval within roughly one refresh plus scheduling tolerance; at 60 Hz aim for the same relative target. Report worst frames and hitches separately. Do not infer smoothness from the average FPS alone.
Repeat with an external display or battery mode only if those are part of the user's play setup. If a frame spike remains, capture its trace and determine whether it is simulation, GPU, shader upload, network correction or browser/display scheduling before adding another rendering effect.
M1 content follow-up¶
The added wolves, journal and camp objectives were checked against the production client. A first-use burst capture exposed one 49.3 ms frame, while the repeat was smooth. Effects loading now warms the shared burst/ring meshes and the world's fog shader variant. The final fresh-page 600-frame turn/movement/effects sample recorded 17.1 ms p95, 19.7 ms worst, zero frames over 33 ms and zero failed shaders at the same 1280 × 633 / DPR 1 automated 60 Hz setup. The full regression set is now 31 tests.
M1 playtest record and measurement limits · Raw M1 browser record.
Commands¶
npm run typecheck
npm run test:smoothness
npm run test:characters
npm run test:environment
npm run build
npm run docs:build
Content-changing protocol tests should run against isolated copied data, especially tests that reset quests or drive world events. Never reset the user's current world as part of a performance check.