Jonas VolmanandClaude Opus 5
9470345c00
_bink_alloc@4 (+494 meaningful). Three hunks, each measured necessary:
- The two match_dassert sites inside the function become match_vassert. The
d-family is a project convenience wrapper (docs/assertions.md), not a claim
about January's text, and the wrapper auto-inlines the small static predicate
where January calls it out of line.
- A `boolean can_allocate` holds the three-operand guard chain. laws_w2 A13: the
helper inlines at 0, 1 or 2 && operands and declines at 3, and with the boolean
the assert line anchors 735/759/786/787/799 and January's ja/jge/jne polarity
put the failure arm first.
- One unit-local `__asm { int 3 }` in the failure arm, admitted by an explicit
owner ruling as a helper under house rule 10.
Evidence for the trap, as the ruling requires it be documented: a capstone census
over all 833 January split objects finds exactly four in-body int3 corpus-wide,
and exactly one in Halo source - this site at 0xd1; the other three are vendor
(binkxbox, d3d8, xapilib). A control replacing the trap with __debugbreak() gives
147 instructions with the int3 relocated from 0xd1 to 0xd4 (it sinks past
`pop edi; mov eax,esi`), and a control with no trap is 496/52 [sha] with a
one-instruction shift through the rest of the body - so the intrinsic provably
cannot pin the trap and only inline assembly reproduces January's placement.
This ruling covers that one instruction only; all allocator logic stays in C.
I verified the minimum-hunk requirement myself rather than assuming it: the trap
alone gives 496 [size 512!=496, relocs 51!=52], trap plus the vassert conversions
gives 480/51, so the boolean is load-bearing for the missing relocation and the
size. fake_match_scan reports the expected single inline-assembly review lead.
Full ninja, parks 273 active / 0 stale / 0 invalid, stable diff vs
scratch/opus5-next150-before.json: gained 8 / 7,328 padded, regressions 0; owner
census adds nothing and correctly drops the 'end bink_alloc' literal January
does not own.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Halo 1 decompilation
This is a work-in-progress decompilation of Halo: Combat Evolved build 2342 (cachebeta.exe, sha256 4cc87b45f721270392a96f1674ed2b5cd4a7bb4355faeab4531d1cf1884d9520).
Agent quick references
- Current campaign house rules and batch/treemap cadence
- Common constants, types, float patterns, tag IDs, and flag conventions
- Shared assertion macros and byte-matching examples
- Supplied CE source maps, recovered names, and next reconstruction packets
- Matching methodology and source-credibility rules
Build instructions
You must source the Halo 1 PAL debug build and the August 2001 Xbox SDK yourself. You also need ninja-build on your PATH.
Extract the XDK/xbox folder from the installer into the repository root such that xbox/{bin,include} are valid paths. Place cachebeta.exe from the Halo 1 build into your repository root. Navigate to the repository and run configure.py in the terminal.
Then, use ninja build to compile the game and report progress statistics, or open the cachebeta.sln VS2022 project under projects on Windows.
Where's all the type information?
We use debug symbols from later Halo games to help map structures, enums, type definitions, function signatures and some variable names. You should obtain a copy of the Halo CEA beta and run it through pdb-decompiler to obtain debug info for yourself. Note that CEA is based off of Halo PC and has its own modifications which make it not 100% accurate to the original Xbox title.