docs(plans): Campaign VM carries the VM2 lesson - a branch that exists is not a branch that runs
Binding rule: when retail gates a mechanism behind a capability, preference, or trysinglepass-style switch, the port is not done until the gate's live value is cdb-read on the PDB-paired client and cited with the binary GUID. Records that the owner's live 'too bright' was the pack-on gamma-space tonemap (VM3), not the detail overlay (+3% fallback / -10% real path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
fe085cadaa
commit
4a69ecd32e
1 changed files with 26 additions and 0 deletions
|
|
@ -46,6 +46,32 @@ AC-specific constants — a number without a decomp/DAT anchor gets a register
|
||||||
row in the same commit — and the pack-off path is the oracle: any slice that
|
row in the same commit — and the pack-off path is the oracle: any slice that
|
||||||
moves a pack-off pixel outside its declared mask is a bug, not a tuning.
|
moves a pack-off pixel outside its declared mask is a bug, not a tuning.
|
||||||
|
|
||||||
|
## Lesson carried into every slice — a branch that exists is not a branch that runs
|
||||||
|
|
||||||
|
VM2 found that Campaign AR's #226 port, the 2026-08-21 findings doc it was
|
||||||
|
briefed from, and the AR review's "probably" were all describing the
|
||||||
|
**fallback** branch of retail's detail pass — the `stage == 0` framebuffer
|
||||||
|
blend that retail only takes when the adapter cannot advertise
|
||||||
|
`D3DTEXOPCAPS_PREMODULATE`. Real hardware (the owner's AMD, and anything
|
||||||
|
modern) takes the single-pass texture-stage branch, which computes a
|
||||||
|
different formula with the opposite sign of effect (darkens, not brightens).
|
||||||
|
The decomp was read correctly three times; what nobody did until VM2 was
|
||||||
|
spend two minutes reading the capability on a live client.
|
||||||
|
|
||||||
|
Binding rule for this campaign and after: **when retail gates a mechanism
|
||||||
|
behind a capability, preference, or `trysinglepass`-style switch, the port
|
||||||
|
is not done until the gate's live value is recorded** — a cdb read on the
|
||||||
|
PDB-paired client, cited in the port's note with the binary GUID. "Grep
|
||||||
|
named → decompile → port" answers what the code *says*; only the live read
|
||||||
|
answers what it *does* on the hardware the game actually ran on. A guess
|
||||||
|
about driver caps ("rarely advertised") is not evidence and must not appear
|
||||||
|
in a review verdict.
|
||||||
|
|
||||||
|
Corollary for brightness questions: the owner's live "too bright" (exposure
|
||||||
|
1.0 → 0.80) was the pack-on gamma-space tonemap (F4, VM3), not this. The
|
||||||
|
detail overlay's fallback brightening is +3 % on building shells only; the
|
||||||
|
single-pass path darkens by ~10 %. Neither explains a scene-wide level.
|
||||||
|
|
||||||
## Slice ledger
|
## Slice ledger
|
||||||
|
|
||||||
| Slice | Closes | Gate |
|
| Slice | Closes | Gate |
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue