KartriderDemoPhysics

KO | EN

gitlite — search

#rust #gemini #animation #typescript #markdown #kotlin #csharp #llm #http #nodejs

KartriderDemoPhysics

(★ 9)

No description available.

파일 탐색기

ZIP 다운로드

- - accessor-cluster-xrefs.txt
  - accessor-cluster.c
  - all-rtti-symbols.txt
  - body-collision-decompilations.c
  - booster-effect-owner.c
  - bufferedsource-rtti.txt
  - camera-axis-helpers.c
  - camera-class-decompilations.c
  - camera-constants.txt
  - camera-constructors.c
  - camera-fov-config.c
  - camera-fov-state-functions.c
  - camera-helper-decompilations.c
  - camera-neighborhood.txt
  - camera-position-math-helpers.c
  - camera-projection-disassembly.txt
  - camera-rtti.txt
  - camera-slerp-decompilation.c
  - camera-slerp-helper-decompilations.c
  - camera-slerp-weight.c
  - candidate-decompilations.c
  - col-59317c.txt
  - collision-build-decompilations.c
  - collision-build-refs.txt
  - collision-callers.txt
  - collision-contact-helpers.c
  - collision-normal-test-disasm.txt
  - collision-query-disassembly.txt
  - collision-query-functions.c
  - collision-response-helpers.c
  - colortable-callers.txt
  - colortable-owner.c
  - colortable-singleton.c
  - colour-symbols.txt
  - config-users.c
  - core-neighborhood.txt
  - core-physics-decompilations.c
  - countdown-functions.c
  - countdown-string-refs.txt
  - course-advance-decompilation.c
  - course-checkpoint-decompilations.c
  - course-class-scan.c
  - course-const-xrefs.txt
  - course-consumer-refs.txt
  - course-element-decompilations.c
  - course-graph-decompilations.c
  - course-init-decompilation.c
  - course-runtime-decompilation.c
  - course-support-decompilation.c
  - course-xrefs.txt
  - demo-effect-extracted.json
  - demo-effect-manifest.json
  - demo-stuff-manifest.json
  - e6-callers.txt
  - engine-symbols.txt
  - find-object-decompilation.c
  - fov-angle-math.c
  - fov-state-callers.c
  - fov-state-callgraph.txt
  - fov-state-offset-users.txt
  - fov-state-writers.c
  - frame-offset-owners.c
  - gate-crossing-decompilation.c
  - grid-build-disasm.txt
  - grid-cell-refs.txt
  - instant-boost-decompilations.c
  - intersect-symbols.txt
  - kart-catalog.json
  - kart-colour-accessors.c
  - kart-colour-apply.c
  - kart-colour-bind-disasm.txt
  - kart-colour-bind.c
  - kart-colour-candidates.txt
  - kart-colour-consumer.c
  - kart-colour-decompilations.c
  - kart-colour-factory.c
  - kart-colour-high.c
  - kart-colour-keyinit.txt
  - kart-colour-keys.txt
  - kart-colour-slots.c
  - kart-colour-xrefs.txt
  - kart-effect-rtti.txt
  - kart-frame-accessor-refs.txt
  - kart-frame-core.c
  - kart-frame-offset-users.txt
  - kart-frame-physics.c
  - kart-physics-init-disasm.txt
  - kart-two-frame-consumer.c
  - kartcolor-getter-xrefs.txt
  - kartcolor-offset.txt
  - kartvisual-getter-xrefs.txt
  - kartvisual-offsets.txt
  - lap-progress-decompilations.c
  - math-vector-helpers.c
  - minimap-accessor-owners.txt
  - minimap-accessor-xrefs.txt
  - minimap-constructors.c
  - minimap-coordinate-path.c
  - minimap-decompilations.c
  - minimap-default-constructor.c
  - minimap-global-vector-init.c
  - minimap-interpolation.c
  - minimap-marker-basis.c
  - minimap-math-helpers.c
  - minimap-param-rtti.txt
  - minimap-projection.c
  - minimap-render-path.c
  - minimap-rtti.txt
  - minimap-runtime-vector-xrefs.txt
  - minimap-scalars.txt
  - minimap-scene.txt
  - minimap-stage-update-disasm.txt
  - minimap-stage-update.c
  - minimap-symbols.txt
  - minimap-track-values.json
  - minimap-update-callers.txt
  - minimap-xrefs.txt
  - new-cut-snapshot.csv
  - oracle-instant-boost.csv
  - oracle-lateral.csv
  - oracle-timed-boost.csv
  - oracle-trajectory.csv
  - physics-field-uses.txt
  - physics-pipeline.c
  - physics-triage.txt
  - projection-build.c
  - projection-field-users.txt
  - projection-fov-setter.c
  - projection-math.c
  - quaternion-helpers.c
  - race-input-functions.c
  - race-progress-functions.c
  - race-progress-symbols.txt
  - ray-query-callsites.txt
  - remaining-neighborhood.txt
  - remaining-offset-users.txt
  - respawn-caller-decompilation.c
  - respawn-decompilation.c
  - respawn-xrefs.txt
  - rho-crypto-functions.c
  - rho-key-functions.c
  - rho-loader-functions.c
  - road-element-reader.c
  - round1.c
  - skidmark-callers.txt
  - skidmark-core.c
  - skidmark-decompilations.c
  - skidmark-final-core.c
  - skidmark-frame-accessors.c
  - skidmark-geometry-disasm.txt
  - skidmark-geometry.c
  - skidmark-manager-core.c
  - skidmark-refs.txt
  - skidmark-rtti.txt
  - skidmark-scalars.txt
  - skidmark-vector-helpers.c
  - sound-api-callers.txt
  - sound-booster-functions.c
  - sound-driver-functions.c
  - sound-slot-users.txt
  - sound-string-refs.txt
  - sound-update-functions.c
  - stream-read-decompilation.c
  - suspension-config-offsets.txt
  - suspension-force-decompilations.c
  - suspension-offset-users.txt
  - texproperty-decomp.c
  - texproperty-rtti.txt
  - texproperty-serialization.c
  - timed-boost-decompilations.c
  - timed-boost-neighborhood.txt
  - tominimap-fields.c
  - toroad-class-scan.c
  - toroad-decode-decompilation.c
  - track-node-class-refs.txt
  - track-node-type-refs.txt
  - trackobject-fields.c
  - trackobject-rtti.txt
  - update-and-drift-state.c
  - velocity-accessor-users.c
  - velocity-accessor-xrefs.txt
  - velocity-frame-helpers.c
  - visual-effect-decompilations.c
  - visual-effect-symbols.txt
  - visual-string-address-refs.txt
  - vtable-57820c-scalars.txt
  - warp-toroad-refs.txt
  - wireproperty-decomp.c
  - wireproperty-helpers.c
  - wireproperty-rtti.txt
- - analyze_new_cut_snapshot.c
- CAMERA_RECOVERY_NOTES.md
- MINIMAP_RECOVERY_NOTES.md
- NEW_CUT_RECOVERY.md
- RECOVERY_NOTES.md
- SKIDMARK_RECOVERY_NOTES.md
- - NuGet.Config
  - Program.cs
  - README.md
  - RhoSafeIndex.csproj
- - Program.cs
  - README.md
  - TrackMeshExporter.csproj
- kart.exe
- README.md
- kart_audio_win32.c
- kart_audio_win32.h
- kart_axis_gizmo_win32.h
- kart_demo_macos.m
- kart_demo_win32_ui.h
- kart_gauge.h
- kart_gearbox.h
- kart_minimap_resources.h
- kart_minimap_win32.c
- kart_minimap_win32.h
- kart_minimaps.rc.in
- kart_model_resources.h
- kart_model_win32.h
- kart_models.rc.in
- kart_params_win32.h
- kart_screenshot_win32.h
- kart_skidmark.rc.in
- kart_skydome_resources.h
- kart_skydomes.rc.in
- kart_sound_resources.h
- kart_sound_win32.h
- kart_sounds.rc.in
- kart_track_scene_resources.h
- kart_track_scenes.rc.in
- kart_track_texture_resources.h
- kart_track_textures.rc.in
- kart_win32.c
- - .gitkeep
  - simulator-3d.png
  - simulator-topdown.png
- COLLISION_DIVERGENCE.md
- COLLISION_PORT.md
- KART_ASSET_VERIFICATION.md
- KART_MODEL_CATALOG.md
- KART_PARAMETERS.md
- ORIGINAL_COLLISION.md
- ORIGINAL_COURSE.md
- PHYSICS_ENGINE_TEXTBOOK.md
- TRACK_ASSET_PIPELINE.md
- TRACK_CODE_MAPPING.md
- kart_camera.h
- kart_countdown.h
- kart_course.h
- kart_demo_data.h
- kart_dynamics.h
- kart_engine_sound.h
- kart_inflate.h
- kart_input.h
- kart_simulation.h
- kart_track_collision.h
- kart_track_scene.h
- kart_track_texture.h
- - AddressReferences.java
  - CameraConstantReport.java
  - CameraRttiReport.java
  - CoreNeighborhood.java
  - DecompileFunctions.java
  - DisassembleFunctions.java
  - KartColourReport.java
  - OffsetUsers.java
  - PhysicsFieldUseReport.java
  - PhysicsTriage.java
  - RaceProgressSymbolReport.java
  - ReadScalars.java
  - RhoLoaderReport.java
  - RttiVtableReport.java
  - SymbolSearch.java
  - VisualEffectSymbolReport.java
- build_macos.sh
- capture_simulator_screenshot.ps1
- derive_course_gates.py
- derive_kart_catalog.py
- derive_kart_constants.py
- derive_track_constants.py
- export_track_meshes.ps1
- extract_track_assets.ps1
- index_track_assets.ps1
- map_track_textures.ps1
- pack_track_scenes.ps1
- pack_track_textures.py
- setup_rho_tools.ps1
- kart_camera.c
- kart_countdown.c
- kart_course.c
- kart_course_data.c
- kart_demo_data.c
- kart_dynamics.c
- kart_engine_sound.c
- kart_inflate.c
- kart_input.c
- kart_simulation.c
- kart_track_collision.c
- kart_track_scene.c
- kart_track_texture.c
- 1786256239.png
- compare_instant_boost_oracle.c
- compare_lateral_oracle.c
- compare_timed_boost_oracle.c
- compare_trajectory_oracle.c
- test_audio_cursor.c
- test_camera_follow.c
- test_countdown.c
- test_course_progress.c
- test_engine_sound.c
- test_inflate.c
- test_kart_dynamics.c
- test_kart_model_assets.c
- test_track_collision.c
- test_track_scene_assets.c
.gitattributes
.gitignore
CMakeLists.txt
README.md

# CDN으로 사용하기

jsDelivr

jsDelivr는 공개 GitHub 리포지토리를 별도 설정 없이 CDN으로 즉시 서빙합니다. 버전과 파일을 고르면 웹페이지에 바로 붙일 수 있는 링크와 예시 코드가 만들어집니다.

버전

파일

링크

예시

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

This workspace contains a clean C reconstruction of the kart dynamics code in
the 2004 `KartRider.exe` demo. It is an evidence-driven behavioral recovery,
not the original source code.

## Simulator preview

### Top-down

![Top-down simulator drifting with skid marks, item boost indicator, speedometer, and track bounds](https://raw.githubusercontent.com/overjoy1008/KartriderDemoPhysics/main/docs/assets/simulator-topdown.png)

### 3D

![3D simulator using the fixed chase camera with boost flame, speedometer, ground grid, and track bounds](https://raw.githubusercontent.com/overjoy1008/KartriderDemoPhysics/main/docs/assets/simulator-3d.png)

Both views run the same 3D physics state and 5 ms substep pipeline, and they are
one program: the top-down renderer projects that state onto X-Y, the 3D renderer
draws it with the existing fixed chase camera, and `C` switches between them.
These screenshots were captured from the current Windows build while drifting
and using the item boost.

## Run the included simulators

No build is required to try the checked-in applications.

On **Windows**, open this file:

- `build-win/kart.exe` — both views in one program; `C` switches between the
  3D chase camera and the top-down projection

The Windows executable is self-contained and can be copied by itself to
another 64-bit Windows 10/11 computer. No asset directory or separate MinGW
runtime DLL is required.

On **macOS**, open one of these application bundles:

- `build-macos/Kart Physics Top Down.app` — top-down view
- `build-macos/Kart Physics 3D.app` — 3D chase-camera view

On macOS, if Gatekeeper blocks the first launch, Control-click the application,
choose **Open**, and confirm once. The ZIP files in `build-macos` are optional
distribution copies; the `.app` bundles are the files to run directly.

## Read the recovery

- **[Physics engine textbook](docs/PHYSICS_ENGINE_TEXTBOOK.md)** builds the
  current implementation bottom-up from vectors and coordinate axes through
  suspension, tire forces, drift states, boosts, drag, collision, and
  quaternion integration. Its equations and update order follow the C code.
- **[Track code mapping](docs/TRACK_CODE_MAPPING.md)** maps the verified
  `T`-menu codes to their Korean original names, historical Item/Racing
  classification, and 1–5 difficulty ratings.
- **[Track asset pipeline](docs/TRACK_ASSET_PIPELINE.md)** documents the
  read-only RHO inventory, minimap/texture extraction, `track.1s` decoding,
  and C-friendly KTRK mesh preparation.
- **[Original collision](docs/ORIGINAL_COLLISION.md)** is a decompilation-only
  account of how the 2004 EXE collides: the 4-unit hashed triangle grid, the
  `property/road` asset flag that decides what is collidable at all, the
  per-wheel ray versus the oriented body box, and the single `0.65` face-normal
  test that separates floor from wall. It records what could not be established
  as well as what could.
- **[Collision divergence](docs/COLLISION_DIVERGENCE.md)** put that account next
  to what this simulator used to do, and **[collision port](docs/COLLISION_PORT.md)**
  records closing the gap: the body is now the original's oriented box and
  13-axis separating-axis test, the ground ray uses the original's 0.65 normal
  threshold, face normals are reported unflipped, the scene mirror no longer
  silently inverts them, and only the subtrees the asset tags `property/road`
  are solid — roughly a quarter of each track's triangles, the rest being
  scenery the original drives through.
- **[Kart parameter tables](docs/KART_PARAMETERS.md)** lists every value the 26
  karts hand to the physics: the five `parameter.xml` dynamics sets side by
  side, which karts use each, and each kart's own body dimensions. All of it is
  recovered, and it is what the `P` editor's **Kart defaults** restores.
- **[Kart model catalogue](docs/KART_MODEL_CATALOG.md)** records, per kart, the
  submesh breakdown of `model.1s`, the three different bounding boxes it yields
  (full, body, wheels) and why only the body one reproduces the physics
  constants, the wheel placement, and what the skins actually contain.
  Re-run it with `python scripts/derive_kart_catalog.py`.
- [Recovery notes](analysis/RECOVERY_NOTES.md) connect recovered formulas to
  executable addresses and supporting reports.
- [Differential-oracle results](analysis/RECOVERY_NOTES.md#differential-oracle-results)
  record the original-EXE calls and frame-by-frame comparison results; the
  captured CSV references are in [`analysis/reports`](analysis/reports/).

## Current recovered scope

- the complete `Dynamics` parameter list and original fallback values;
- speed-attenuated steering angle;
- front/rear lateral slip and tire force calculation;
- grip, drift, and drift-trigger force modes;
- local lateral force plus roll/yaw torque outputs.
- four-contact suspension and gravity response;
- drift input/trigger state and original timing;
- linear/angular air drag and grounded quadratic drag;
- fixed-step linear velocity integration.
- the original `speed <= 5` non-drift lateral branch and `CornerDrawFactor`
  forward draw force;
- the runtime grounded-drag field, including the original `x4` enter and
  `x0.25` leave transitions;
- triangle-contact linear collision response with the original restitution and
  tangential-loss constants.
- forward, reverse, drift-escape, boost, grip-brake, and slip-brake forces.
- inverse-inertia construction and angular velocity integration.
- four-wheel ray contact generation and compression history;
- quaternion pose integration and the original anti-flip retry guard;
- hard/late body-collision angular response;
- an engine-independent world-query interface and complete fixed 5 ms
  simulation pipeline.
- the complete `ChaseCameraman` mode-0 update: a persistent camera quaternion
  interpolating toward the kart's orientation at `min(dt / 400 ms, 1)` — which
  is what leaves the kart visibly turned across the view during a deep drift —
  an asymmetric speed filter (10 s easing out, 100 ms pulling in), chase pitch
  `speed/400 + 0.25`, rear distance `5.5 + speed*0.045`, height `speed/60 + 3`,
  a booster-linked 75-to-110 degree field of view, and the Z-only smoothing of
  the final camera position. See
  [camera recovery notes](analysis/CAMERA_RECOVERY_NOTES.md).
- the kart sound driving from `FUN_00452E60`: the engine loop's pitch and
  volume both follow `speed * 0.01171875 + 0.25`, refreshed only every 64 ms,
  with volume pinned at 1.0 from speed 64 and pitch pinned at 1.5 from speed
  128; the drift loop runs exactly while the kart's drift flag is set; the
  booster is triggered by the same flag that widens the chase camera's field of
  view; crash and shock are one-shots at `clamp(magnitude * k, 0.1, 1.0)` with
  `k` of 0.1 and 0.04. See [the sound section](#sound) below.
- the original HUD `|velocity| * 3.6` km/h conversion;
- all 26 playable demo kart presets, checked against the demo's own
  `Data/kart.rho`: 416/416 `Dynamics` values match each kart's `parameter.xml`,
  and all 78 dimension constants are reproduced exactly from the body mesh of
  its `model.1s`. See
  [kart asset verification](docs/KART_ASSET_VERIFICATION.md); re-run it with
  `python scripts/derive_kart_constants.py`. All 26 **models** are embedded too,
  so the drawn kart is now that `model.1s` rather than a box built from its
  dimensions; `M` switches back to the box and `B` shows the bounding volumes.
  See [the kart model catalogue](docs/KART_MODEL_CATALOG.md).
- all 13 demo track mesh-AABB sizes, every one of them re-derived from that
  track's decoded `track.1s` mesh so the scene, walls, minimap and spawn share
  one source.

The source addresses are recorded next to recovered formulas. Raw Ghidra output
and ranking reports are kept under `analysis/reports`; reusable headless scripts
are under `scripts/ghidra`.

## Binary differential verification

`kart_binary_oracle.exe` starts the installed 32-bit demo, allocates an isolated
synthetic kart object, and calls the original fixed-address physics functions.
It does not modify the live game kart or save data. Two captured references are
kept under `analysis/reports`:

- 140 lateral-force/state frames covering grip, trigger, held drift, release,
  linger, and automatic slip;
- 240 chained frames covering force accumulation, drag, velocity integration,
  pose integration, and drift entry/maintenance/exit.

The current recovered implementation scores `1.000000` average similarity in
both suites. The trajectory suite's worst normalized scalar similarity is
`0.999989`, with zero drift-flag mismatches. These numbers describe the tested
synthetic flat/planar scenarios, not the unrecovered proprietary track query.

## Build from source

```powershell
cmake -S . -B build
cmake --build build
ctest --test-dir build --output-on-failure
```

`kart_simulation.h` exposes callbacks for ground rays and body contacts. This
keeps the recovered dynamics independent of the demo's proprietary scene and
triangle-query implementation while preserving the original query geometry
and update order.

After a Windows build, launch `build/kart.exe`. It uses the following controls:

| Action | Windows | macOS |
|---|---|---|
| Accelerate / brake or reverse | Up / Down | Up / Down |
| Steer | Left / Right | Left / Right |
| Drift | Shift or `W` | Shift or `W` |
| 3-second item boost | Ctrl or `D` | Command or `D` |
| Switch camera (chase / top-down) | `C` | — |
| Show or hide the motion vectors | `V` | — |
| Cycle the drift gauge model | `G` | — |
| Open the kart parameter editor | `P` | — |
| Choose kart / track | `K` / `T` | `K` / `T` |
| Toggle grounded-drag trigger | `F` | `G` |
| Save a screenshot | `S` | — |
| Dismiss the `K` / `T` menu | `Esc` | `Esc` |
| Reset (the countdown only reruns on a track change) | `R` | `R` |

`Esc` only closes the kart and track menus. The window is closed the usual way,
with Alt+F4 or the title bar. Keys are ignored unless the demo window is the
foreground window, so the kart will not drive while you are typing elsewhere.

Press `K` or `T` to open a selectable list. Use the mouse, or the arrow keys
and Enter, to apply one of the 26 kart presets or 14 track bounds immediately.
The track list shows the supplied Korean public name, original `I`/`R` mode
classification, and difficulty for all 13 identified tracks, plus the synthetic
`flat_test` reference track described below. The Track Map
panel uses each archive's original `xt_minimap.png`, and every track resets at
the centre of its decoded start-line road quad. Only Forest Log and Village
Overpass have their start *direction* checked against the original game; see
the confidence boundary below.
Both views live in the same executable and share one simulation, so `C` switches
between them without disturbing the kart.

### Telemetry panels

Beyond the HUD's debug lines, the window shows three read-outs. The bottom-left
panel lists the whole rigid body state: drift phase and slip angle, position,
velocity, acceleration, angular velocity, body-axis speeds and `up_z`, the
steering and drift timers, boost timers, the active force and drag constants,
and what the last step resolved. Above the speedometer, a wheel figure shows
each suspension contact's compression over its tire. `V` overlays the kart's
motion vectors: velocity, its forward and lateral split, and the acceleration
the last step produced.

`P` opens a parameter editor over the running kart's `KartDynamicsConfig`.
Edited values apply on the next step without a reset; **Kart defaults** restores
the selected kart's own `parameter.xml` values.

### `flat_test` reference track

The demo opens on `flat_test`, a synthetic track with **no mesh**: just the
flat ground plane and the cyan AABB walls. It exists to isolate the recovered
physics from the decoded scene geometry, so anything odd on screen is the
dynamics rather than a triangle query. Its footprint matches Forest Log
(`896.391 x 807.183`) and it is centred on the world origin. Press `T` to switch
to any of the 13 real tracks.

### World axis gizmo

Both views draw a **world** X/Y/Z triad below the HUD's debug lines in the
top-left corner: X red, Y
green, Z blue, in the usual convention. The arrows always show the world frame,
never the kart's body axes, so the widget shows how the world is oriented from
the current viewpoint — in the 3D demo it turns as the chase camera yaws. An
axis pointing nearly straight at or away from the camera has no useful screen
direction, so it is drawn with the "out of / into the page" ring symbol instead
of an arrow; in the top-down view that is always Z.

## Top-down view

The `C` key's top-down renderer runs the full 3D
physics state and renders only the X-Y projection using the
Win32 API, so no graphics package is required. It starts on `cotten5` on the
`flat_test` reference track — the kart is a simulator-side choice, since the
demo's own `kartlist.xml` offers only `burst3`. The camera follows the kart over a
10-unit reference grid. The top-right bounds panel shows the full track, the
selected kart's exact width and length, and its current position as an oriented
triangle.

The camera is oriented so world **+Y points up** the screen and world +X points
left, matching the original minimap artwork, so the main view and the Track Map
panel always agree. Both axes are negated together, which is a rotation rather
than a mirror, so steering handedness is unchanged.

- Up: accelerate
- Down: reverse or brake
- Left, Right: steer
- Shift or `W`: drift
- Ctrl or `D`: start the original 3-second item boost
- `C`: switch between the chase camera and the top-down projection
- `V`: show or hide the motion vectors
- `G`: cycle the drift gauge model
- `P`: open the kart parameter editor
- `K`: open the 26-entry kart selection list
- `T`: open the 14-entry track selection list
- `F`: emulate the original ground-drag trigger enter/leave (`x4` / `x0.25`)
- `S`: save a screenshot
- `R`: reset

Both views show a large lower-right km/h gauge. The `K` and `T` popup
lists support mouse selection or the arrow keys and Enter, and check the
currently active preset.

The recovered original instant boost is automatic: finish a forward drift,
release Up, then press Up again while the HUD shows `INSTANT READY` (a 0.5
second window). It applies the original 1.5x forward-force multiplier for 0.5
seconds. Ctrl/`D` remains the separate external boost control.
The item boost starts only on a new key press while accelerating, lasts 3000
milliseconds, and ignores further booster presses while item or instant boost
is already active. Release and press Ctrl/`D` again after expiry to reuse it.

During any drift state, the renderer leaves fading twin rear-wheel skid marks.
Boost is shown by a cyan kart, a rear flame, and a `BOOST ON` HUD indicator.
For the original new-cut input, keep the first steering direction held and
press the opposite direction during the same drift. The most recently pressed
direction owns steering instead of the two keys cancelling to zero, so the
existing opposite yaw torque can straighten the kart without a guessed extra
force.

## 3D view

The startup view uses the same recovered
physics and world callbacks, with a software-rendered perspective chase camera.
All 13 real tracks embed and draw the decoded original `track.1s` KTRK scene
mesh; `flat_test` deliberately has none.
The scenes are stored as raw DEFLATE inside the executable and inflated at
startup by `src/kart_inflate.c`, which keeps 12.1 MB of mesh data down to
3.7 MB of resources and needs no external library. No asset directory is needed
at run time.
Every mesh in an embedded scene is solid, scenery included. What a face is used
for comes from its **normal**, not its name: `|n_z| >= 0.20` is drivable ground
for the wheel rays, `|n_z| <= 0.55` is a wall for the body. The `road`/`wall`
flags come from substring matches on node names, which are unreliable enough
that they now only pick the wireframe colour — they miss Korean node names
entirely, and used to let the kart drive straight through rocks and ledges.
Meshes are rejected by their bounds before any triangle is tested, so covering
the whole scene costs 0.8–2.5% of a 5 ms substep. The recovered rectangular AABB
remains an outer safety wall. The kart body is sized from the selected model
AABB.

Those collision faces are also shaded, translucently, so the surface the physics
actually uses is visible rather than inferred from wireframe alone: warm sand
for ground, blue for walls, using the same thresholds as
`src/kart_track_collision.c`. The fill is composited at roughly one third
opacity, so the wireframe and the ground grid stay readable through it.

### Sound

The Windows build plays the demo's own effect samples — `motor.wav`,
`drift.wav`, `crash.wav` and `shock.wav` from `kart.rho`, and
`booster/booster.wav` from `sound_fx_item.rho`. All five are 16-bit mono
22050 Hz PCM and are embedded in the executables byte for byte.

The driving logic in `src/kart_engine_sound.c` is recovered from `FUN_00452E60`
and `FUN_00458000`; `tests/test_engine_sound.c` pins its constants. Playback is
`demo/kart_audio_win32.c`, a small streaming mixer over `waveOut` with per-voice
looping, volume, and pitch by resampling — no third-party audio library. A
machine with no output device simply runs silent.

Two details worth knowing. The engine volume curve is continuous, reaching 1.0
exactly at speed 64, but the pitch curve is not: just under speed 128 the ramp
has reached about 1.75 and then steps down to the 1.5 cap. That is what the
original does. And there is no separate instant-boost sound — the original
triggers `booster.wav` from the kart's vftable slot 26 flag, which covers the
item boost and the instant boost alike.

### Race start countdown

The demo opens on a countdown recovered from `FUN_00451EB0` / `FUN_00456CD0`,
which are the same state machine at two different field offsets. Entering the
ready state sets `deadline = now + 7000 ms`; the cues then fire as the deadline
approaches, each tested as `deadline <= now + offset`:

| Threshold | Cue |
|---|---|
| `deadline - 3000` | `count_3` |
| `deadline - 2000` | `count_2` |
| `deadline - 1000` | `count_1` |
| `deadline` | `count_go`, every kart released |

The throttle does nothing until GO. Pressing forward within **±100 ms** of the
deadline grants a **1000 ms** boost — the start boost, from the accelerate
action of the input handler `FUN_004529D0`. It runs through
`GoKart_StartTimedBoost` at `0x00431AB0`, which raises the same flag vftable
slot 26 reports, so it drives the booster sound and the camera's wide field of
view exactly like an item boost. The lights run once per race: `R` and the
out-of-world respawn put the kart back on the line without them, and a track
change starts a new race and reruns them. Holding drift with the throttle before
GO revs the booster — the idle loop plays and the kart takes on the boost look,
but no other booster works until the line drops.

One simulator-side rule: releasing the accelerator ends a boost immediately
rather than letting its timer run out. The original only expires the timer. The
booster and rev samples follow the state the same way the drift loop does: a
boost that is cut short stops its sample instead of playing out.

### Drift gauge — inferred, not recovered

> **Everything in this section is a hypothesis.** The original's gauge-charging
> function is **not** in the recovered set: no address, no pinned constant, no
> test. What *is* recovered is the rear-tire slip term the models are built out
> of. Treat the gauge as a test bench for competing guesses, not as part of the
> recovery. Nothing here feeds the physics — it only decides when a booster
> becomes available.

The starting observation is that the four things players report — speed, entry
angle, escape force / feathering, and slope — may not be four terms in a
charging formula but four ways of maximising one hidden quantity: how far the
rear axle slides sideways. The engine already computes that, for the rear tire:

```
S_r = (-v_s + 0.5*w_z) / max(|v|, 5)          recovered, kart_dynamics.c
```

Multiplying by speed removes the divisor, so above 5 m/s the two forms agree:

```
dG/dt = Kg * |v| * |S_r|   ==   Kg * |-v_s + 0.5*w_z|      hypothesis
```

`G` cycles the three models the simulator implements, so they can be compared
back to back:

| Model | Charge rate | What it assumes |
|---|---|---|
| `INFINITE BOOSTER` | fills at once on any drift | the pre-gauge behaviour, kept for reference |
| `SLIP INTEGRAL` | `Kg·\|v\|·\|S_r\|` | the charging function reads only the slip |
| `SLIP x SUSPENSION` | `Kg·\|v\|·\|S_r\|·W` | it also reads the wheel contacts |

`W` is the contact weight, and it is the *most* speculative part here:

```
W = 1 + Ks * clamp((left_load - right_load) / total * sign(v_s), 0, Ks_max)
```

with the loads being the paired suspension compressions, so a slide whose load
has moved to its outside charges faster. There is no evidence in the recovered
code that any such weight exists; it is only what the "slopes charge better"
report would look like if the charging function read the contacts directly.

**The experiment that separates the two.** Hold the same `|v|`, `v_s` and `w_z`
on flat ground and on a bank. If the charge rate matches, the slope's effect is
just its effect on `v_s` and `w_z`, and `SLIP INTEGRAL` is enough. If the bank
charges faster with everything else matched, the charging function reads the
contacts. The telemetry's `GAUGE` line prints the live `rate` and `W` for this.

Charging is gated on `grounded && drift && |v| > 5`, all three of which are
simulator-side choices. The remaining rules are arbitrary and exist only to make
the models playable — they are **not** claims about the original:

- The gauge holds visibly full for the rest of the drift; the booster is handed
  over when the drift ends, so one drift yields at most one booster.
- A drift that breaks part-way keeps its charge for the next one.
- Two booster slots. Filling with both taken throws the booster away.
- `Kg`, the full value, `Ks` and its clamp are all editable under `P`. The
  defaults (`Kg 4.0`, full `200`, `Ks 1.0`, max `1.0`) are placeholders picked
  for feel — no video or capture has been fitted to them yet. Fitting `Kg` to a
  measured run is the obvious next step and has not been done.

The implementation is `demo/kart_gauge.h`, kept out of `src/` deliberately so
nothing inferred sits beside the recovered engine.

### Falling out of the world

The scenes only carry road triangles where the original track had road, so
leaving the road — off an edge, or through a gap at speed — drops the kart into
a void it can never land in. The simulator detects this and respawns
automatically, showing `FELL THROUGH THE TRACK - RESPAWNED` for a moment. The
threshold is `kart_demo_track_fall_limit()`: 40 units below the lowest geometry
in that scene, far enough that landing hard on the lowest road never trips it.
Its input signs, frame stepping,
runtime drag trigger, item/instant boost handling, and
kart/track selection match the top-down demo. Fading rear-wheel skid marks,
boost flame and body color, heading/velocity vectors, slip telemetry, and the
full boost/drift HUD are projected into the chase-camera view. Controls match
the top-down demo. The ground grid follows the camera over the large original
track footprint, boundary lines are clipped at the camera near plane instead
of disappearing, and the top-right bounds map keeps the cyan track perimeter
visible even when the physical wall is hundreds of metres away. Both bounds
maps use an oriented kart triangle without a separate direction-vector line.
Escape
additionally closes the window.

## macOS demos

The same top-down and 3D simulations can be built as native Cocoa application
bundles on macOS. The macOS renderer uses only AppKit/Core Graphics supplied by
the operating system; no third-party graphics package is required. Physics,
kart/track presets, flat-world collision callbacks, skid marks, bounds map,
speedometer, and the `K`/`T` selection menus are shared in behavior with the
Windows demos. The existing fixed 3D chase view is preserved.

On a Mac with CMake and either Xcode or the standalone Xcode Command Line
Tools installed:

```sh
bash scripts/build_macos.sh
```

This builds and tests both applications, then creates directly executable app
bundles plus ZIP copies for distribution:

- `build-macos/Kart Physics Top Down.app`
- `build-macos/Kart Physics 3D.app`
- `build-macos/kart_topdown-macos.zip`
- `build-macos/kart_3d-macos.zip`

CMake's intermediate files are kept separately in the hidden
`.build-macos` directory; only `build-macos` contains files intended for use or
distribution.

macOS uses native `.app` bundles rather than Windows `.exe` files. Extract a
zip and open the contained application. The script applies a local ad-hoc
signature; because it is not an Apple Developer ID signature, the application
may require Control-click, then **Open**, the first time it is launched.

Controls match Windows except that the item-boost modifier is **Command**:

- Arrow keys: drive and steer
- Shift or `W`: drift
- Command or `D`: boost
- `K`: kart list
- `T`: track list
- `G`: grounded-drag trigger
- `R`: reset

## Confidence boundary

Parameter names/defaults and the core formulas are directly supported by the
listed executable addresses in `analysis/RECOVERY_NOTES.md`. Kart dynamics and
dimensions are verified against the demo's own `kart.rho` by
`scripts/derive_kart_constants.py`; the kart's drawn shape is not, and remains a
box rather than the asset mesh. All 13 track bounds and start
lines are derived from the decoded `track.1s` meshes by
`scripts/derive_track_constants.py`, and all 13 use the selected yellow KTRK
triangles for ground and wall contact on Windows. The exact proprietary
node-selection query is still not claimed as recovered.

The **drift gauge is on the far side of that line**, and further out than
anything else in this repository. No charging function was recovered — only the
rear-tire slip term the models are assembled from — so its formulas, its
coefficients, the one-booster-per-drift rule and the two slots are all inferred
or invented, and none of them is pinned by a test. It lives in `demo/`, never in
`src/`, and it changes nothing about how the kart moves.

The start **direction** is the weakest link. A start line's position and its
axis are readable from the stripe quad, but nothing in `track.1s` records which
way round the lap is driven, so the simulator assumes the **positive world
axis**: a Y-axis start line faces world +Y, an X-axis one faces world +X. Those
are the same axes the corner gizmo shows. The track
table grades each entry:

| Grade | Tracks | Meaning |
|---|---|---|
| `confirmed` | `forest_I01`, `village_R01` | direction compared against the original game |
| `assumed dir` | 9 tracks | stripe clearly elongated, so the axis is certain; the sign is assumed |
| `assumed axis` | `ice_I01`, `ice_I02`, `ice_R01` | start quad nearly square, so even the axis is a guess |

A wrong sign only means the kart starts facing backwards; press `R` after
turning around. Correcting one is a single enum change in `src/kart_demo_data.c`.

KartriderDemoPhysics

파일 탐색기

# CDN으로 사용하기

Was this content helpful?

Recent Feedback

Download README