Files

T

ReaperOfVeriod 615ff937ea Decomp advanced 18 commits to 8a174cb; 14 new matched functions land in our .text

Checked upstream as asked. The vendored checkout moved from aca4f59 to 8a174cb,
18 commits ahead of origin/master.

What the update is: all 18 commits are src/game function-matching work. No header,
no docs, no config, and crucially no change to config/levels/functions.tsv -- so
the function extents and level catalogue this project depends on are unaffected.

What is usable: 14 of the newly matched functions fall inside the overlay .text
(0x2a3b80-0x447900), which makes them decomp addresses verified against the same
code this project runs:

    002A7750 002AA800 002B3868 002B6120 002B7E28 002C7748 002CD8C0
    002D5E98 002DDEC8 002DF1B8 002E7018 002F5220 002FC8D0 00300618

That matters because PROVENANCE.md records exactly this split: the decomp's struct
layouts were usable while its function addresses were not (they failed for the moby
class loader). Addresses that are now matched inside our own overlay are the
reliable kind, and 20655c7 needs precisely that to follow UpdateCamera_6 out of
lvl.camvtbl without repeating the mistake that cost the moby_anim chase.

What it does not give: none of the 14 is camera, frustum or GS code. The bodies are
game logic and toolchain-status material -- one is a header-offset relocation pass,
another raises a flag and forces a state word out of {6,7}. So the frustum hunt
does not advance from this, and the next step remains verifying UpdateCamera_6's
address against the overlay and reading the function that writes 0x18aa70.

Vendored checkout is gitignored, so moving it changes nothing committed except the
PROVENANCE note recording the pin and what was in the update.

2026-10-15 03:33:31 +02:00

7.2 KiB

Raw Permalink Blame History

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

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

Update 2026-10-15: decomp advanced to 8a174cb

Vendored checkout moved from aca4f59 to 8a174cb, 18 commits ahead (origin/master). All 18 are src/game function-matching work; no header, doc, config or config/levels/functions.tsv changes, so the function extents and level catalogue this project uses are unaffected.

What is new and usable: 14 of the newly matched functions fall inside the overlay .text (0x2a3b80-0x447900), so they are decomp addresses verified against the same code this project runs:

002A7750 002AA800 002B3868 002B6120 002B7E28 002C7748 002CD8C0
002D5E98 002DDEC8 002DF1B8 002E7018 002F5220 002FC8D0 00300618

None of them is camera, frustum or GS code -- the bodies are game logic and toolchain-status material. Recorded because matched-in-overlay addresses are the thing PROVENANCE.md says is reliable here, and 20655c7 needs exactly that kind of anchor to follow UpdateCamera_6 from lvl.camvtbl.

7.2 KiB Raw Permalink Blame History