Files
Going-Commando/PROVENANCE.md
T
ReaperOfVeriod f182a4a0ac Transcribe the 256-byte MobyInstance; oClass closes the instance-to-routine loop
The decomp carries an authentic MobyInstance layout of 0x100 bytes with every
field named. It is now in gc_formats::moby with a 67-entry offset map, attributed
as a transcription rather than presented as our own finding.

Two fields matter:

    0x40  animSeq      animation sequence pointer
    0x44  animSeqT     animation time parameter
    0x48  animSpeed    playback speed
    0x50  animLayers   animation layer list
    0x57  jointCnt     joint count -- non-zero means the moby is skinned
    0x58  jointCache   joint matrix cache
    0xBC  oClass       object class id -- the dispatch key

OCLASS CLOSES A LOOP THAT HAS BEEN OPEN FOR SEVERAL COMMITS. It is the field the
runtime uses to reach the lvl.vtbl handler tables, so an instance and its routine
are now linked by a named offset, rather than by an assumption about which axis
the two tables share. That assumption -- the positional correspondence -- is still
refuted, and still does not need to be true.

jointCnt and jointCache settle something from earlier in this log BY CONTRADICTION
rather than confirmation. A tie vertex's i16[3] was tested as a skin/joint index
and disproved: vertices sharing it were 0.95x FARTHER apart than vertices differing
in it. That stands and is unaffected -- this is the moby struct, and a moby is a
different object from a tie. Recording the distinction rather than letting "joints"
appear in two places look like a confirmation of the earlier hypothesis.

WHAT THIS DOES NOT DO IS FIND moby_anim. It names the instance-side state, so the
asset to locate is whatever those pointers reference, and we still do not know
where that is. The item's unblock condition is now sharper -- it needs the data
behind those pointers, not the struct.

PROVENANCE, AND WHAT THE TEST CAN ACTUALLY CHECK

This is not verified against disc data and cannot be: moby instances are runtime
objects and nothing of that shape is in the container. The test asserts what can be
asserted without the bytes -- offsets ascend, do not overlap, the last field lands
exactly on 0x100, and o_class sits at 0xBC immediately before triggers.

Worth keeping distinct from the collision finding. That project's FUNCTION ADDRESSES
did not transfer: they landed in NOBITS memory. A struct's field order is a
different kind of claim from an address in a program's layout, so one failing does
not impeach the other -- but the distinction is real, and PROVENANCE.md now records
which is which rather than citing the project as a single authority.

268 tests.
2026-10-14 03:47:15 +02:00

6.2 KiB

PROVENANCE

This project is built on the work of other people. Their licences apply to their code, and those notices travel with anything derived from it.

Summary

Project Role Licence Code copied into this repo?
OpenRAC/rac2-gc-decomp Byte-exact reconstruction research for the same disc (SHA-256 verified identical) -- supplied $gp, the .lit load base, the seven-section program layout, the lvl.vtbl/lvl.camvtbl/lvl.sndvtbl dispatch record shapes, and the 256-byte MobyInstance field map transcribed into gc_formats::moby GPL-3.0-or-later Not yet; vendored read-only at vendor/rac2-gc-decomp. Note: its function addresses did not transfer (they land in NOBITS memory); its struct layouts are used as layout claims, not verified against disc bytes
ReRAC Native Rust/Bevy port of Ratchet & Clank (2002) — the architecture this follows ISC Not yet; derived from, attribute when used
OpenRAC / rac2-gc-decomp Matching decompilation research for this game MIT No — consulted for documentation
rac2-gc-decomp community reference Engine architecture notes, moby struct layout MIT Documentation only
Wrench Insomniac container format documentation GPLv3 No. Specification reference only
RAC2Decomp Functional decompilation, PAL MIT Not used — see below

Game content: none

No game assets, disc images, extracted data, BIOS dumps or proprietary toolchains are or may be committed to this repository. The build takes the user's own legally obtained disc as input. This is enforced by .githooks/pre-commit.

Ratchet & Clank is a trademark of Sony Interactive Entertainment. This is an unofficial fan project, not affiliated with or endorsed by Sony Interactive Entertainment or Insomniac Games.


ReRAC — ISC

The direct model for this project. ReRAC re-implements the first Ratchet & Clank as a native Rust application on Bevy, reading assets from the player's own disc. This project follows the same architecture for the second game.

What we take from ReRAC:

  • The architecture. Crate split (formats / extract / game / engine / video), Bevy 0.19.1, the PS2 float-model discipline, and the milestone gating style.
  • Overlay relocation. rc-formats::level_overlay implements relocation-tolerant code-identity matching so one level's function can be found on every other level. R&C2's 27 overlays have the same seven-section layout (.lit, .bss, .data, lvl.vtbl, lvl.camvtbl, lvl.sndvtbl, .text), so this machinery transfers directly. It is the single most valuable thing we inherit.
  • Verified format specs. docs/formats/disc_layout.md documents all four R&C games' container layouts, derived from behavioural analysis.
  • Discipline worth copying. Golden tests against committed snapshot hashes; bit-exact CPU/GPU identity checks; documenting negative results.

ISC permits use, modification and redistribution with the notice intact. When code is derived from ReRAC it must carry:

Copyright (c) 2026 ReRAC contributors
Licensed under the ISC License.

Pinned checkout: vendor/rerac at commit d00cb00ad4018f776556e72640dcba438d098a77 (2026-10-09). Not tracked by git — clone it yourself; the commit is recorded so everyone uses the same one.

Note that ReRAC targets a different game. Its per-level documentation is a useful hint about Insomniac's engine in general, but R&C2's spherical worlds changed roughly 50,000 lines of gameplay code, so nothing about R&C1's movement, camera or level geometry should be treated as directly applicable.

OpenRAC / rac2-gc-decomp — MIT

Matching decompilation research for this game, targeting exactly our disc (SCUS_972.68 v1.01). It reconstructs the boot ELF and all 27 level overlays byte-for-byte, and publishes verified struct layouts, symbol names and engine documentation.

We use it as a reference, not as source. Its value is that it tells us what the structures are, which saves a great deal of guessing.

Its matching progress is low (~1.6% of code in C) and byte-matching is not a prerequisite for this port anyway — it is a verification technique. We are not pursuing a byte-identical rebuild.

Wrench — GPLv3, specification reference only

Community documentation and tooling for Insomniac's container formats. We use the written format specifications as a reference for how the data is laid out.

No Wrench code is copied into this repository. That is deliberate and load-bearing: copying GPLv3 code would impose GPLv3 terms on everything derived from it. Clean-room reimplementation from a written specification does not. If this boundary is ever crossed, the licensing of this project changes and AGENTS.md must be updated to say so.

RAC2Decomp — not used

A functional (non-byte-matching) decompilation of the PAL release. It is recorded here only so its absence is a decision rather than an oversight.

The rac2-gc-decomp community reference explicitly flags it as "criticized by community for questionable provenance and non-clean-room C code. Avoid copying." Given that we are building a reimplementation and its provenance is disputed, we do not use it. It is also the wrong region: PAL, 50 Hz.

Third-party libraries

Rust dependencies keep their own licences; see Cargo.lock and each crate's LICENSE file. Notable ones:

  • Bevy (MIT / Apache-2.0) — application framework and wgpu renderer.
  • wgpu / wgpu-hal / wgpu-types (MIT / Apache-2.0) — GPU abstraction used for the Graphics Synthesizer reimplementation.
  • bytemuck (Zlib OR Apache-2.0 OR MIT) — zero-copy casts over asset structures.
  • thiserror, anyhow (MIT OR Apache-2.0) — error handling.

When you add a dependency or port code

  1. Record it in this file, with its licence and what you took.
  2. Keep the upstream notice intact in any file containing derived code.
  3. If it would change this project's licensing terms, stop and say so first.