The dinosaur jump: two models from the same constants
Three numbers are pinned: GRAVITY = 0.6, INITIAL_JUMP_VELOCITY = 12, MIN_JUMP_HEIGHT = 35, applied at FPS = 60 inside a 600×150 stage. None of them tells you the apex. Both readings run at once, and the measurements that would settle the disagreement are listed with the procedure.
Independent, and not the official lab. The project publishes its own interactive example covering the speed rule. This lab covers the jump arc. Source read: wayou/t-rex-runner @ 5455bfa408ec6b707c7300ff194b7390733a766d, index.js, 90,241 bytes. Copyright the Chromium Authors, BSD-style licence; the mirror is by @liuwayong. Pin the commit. The branch paths we used now 404.
Discrete, per frame
apex 126.0 px · 20 frames to apex · 700 ms airborne
Time-scaled
apex 120.0 px (v²/2g) · 333 ms to apex · 667 ms airborne
Measured refresh
measuring…
Distance while airborne
253 distance units at landing — a % 700 test is a prediction, not a confirmed scale
Constants
Run it
Space or ↑ also jumps, unless you are typing in a field. The dashed curve is Model A. The solid curve is Model B. The block animates on Model A.
Diff against the real game
Open the offline page, hold the key, and measure with a screenshot: pixels from the ground line, and airtime from a 60 fps recording. The verdict is computed from what you type.
| Quantity | Model A | Model B | You measured | So… |
|---|---|---|---|---|
| Apex height (px) | 126.0 | 120.0 | — | |
| Time to apex (ms) | 333 | 333 | — | |
| Airtime, full hold (ms) | 700 | 667 | — | |
| Apex at 120 Hz | unchanged | unchanged | — | |
| Airtime at 120 Hz | halves | unchanged | — |
Three measurements that would break this page
A lab nobody can falsify is decoration.
| # | What to change | Model A says | Model B says | What it settles |
|---|---|---|---|---|
| 1 | Jump at speed 6 versus near speed 13, holding the key the whole time | Identical arc. startJump receives currentSpeed, and our constants do not use it | Identical | Any real difference means velocity is speed-dependent and INITIAL_JUMP_VELOCITY is not the whole story |
| 2 | Release the key the instant you press it | Descent begins once height has cleared the floor | The continuous apex, with 35 px as a separate floor the formula does not include | Whether MIN_JUMP_HEIGHT is a floor on height or a floor on duration |
| 3 | Run the real game on a 120 Hz display | Height the same, airtime halves | Both unchanged | Per-frame stepping versus time-scaled integration |
How to reproduce the read
Fetch index.js at the pinned commit SHA (not the branch — the branch
paths now 404). From Runner.config, report: GRAVITY,
INITIAL_JUMP_VELOCITY, MIN_JUMP_HEIGHT, SPEED, ACCELERATION, MAX_SPEED,
INVERT_DISTANCE, BOTTOM_PAD, and the FPS constant. Give each one its
line. Then separately report every call site that PASSES a value into
startJump, update or endJump, because that is where speed-dependence
would appear. Finally state which jump-related constants you could not
locate, and do not guess them.The fetch that produced this page was truncated before the end of the file, so the player object's own config block — where a maximum-height constant would plausibly sit — was never read.
What this lab is not. No sprite from the original game is served here. The drawing is ours. The stage height of 150 px is quoted with attribution so you can check the scaling. Upstream is BSD-style, © 2014 The Chromium Authors: the mirror.