ReaperOfVeriod/Going-Commando
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Camera state: 2,005 per-frame float triples, one singleton candidate

Browse Source 
The guard-band clip test's blocker is named in core-data-regions.md: the algorithm
needs the camera and the frustum, both per-frame, so it needs a savestate. Two
savestates give that as a differential -- anything that moved is per-frame state --
without needing to know where the camera lives.

Frames .01 and .04, 33,554,432 bytes each. Of every 16-byte-aligned triple of
finite floats with magnitude 0.001..100,000, 2,005 differ.

Two shapes, clearly different things: the 0x1886xx block repeats one triple four
times at 16-byte stride, which is a per-object array, and 0x18aa70 holds a
near-unit vector that reads as a direction. 0x152c70 is a singleton,
[247.000, 194.000, 49.890] -> [300.170, 227.480, 128.000], in the range Aranos
occupies.

Not claimed as the camera. 2,005 candidates is not a shortlist and a plausible shape
is not evidence -- this stretch has produced enough of those.

Three confirmation steps recorded, cheapest first: smooth motion across .01-.04, a
singleton rather than an array element, and perturbing the camera in an emulator to
watch that one address change. The first two need only the savestates already on
disk; the third is what the lighting verification used.

286 passing with the disc present and GC_SSTATE set, clippy clean.
This commit is contained in:
ReaperOfVeriod
2026-10-15 02:15:05 +02:00
parent e3e0a30030
commit a991088103
2 changed files with 144 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
crates/gc-extract/tests/disc.rs
+94
View File
@@ -5051,6 +5051,100 @@ fn occ(hay: &[u8], needle: &[u8]) -> Vec<usize> {
.collect()
}
/// Scratch: which gameplay section holds a run of point lights?
#[test]
fn scratch_point_lights() {
let Some(data) = extracted_root() else {
eprintln!("skipped: unpack the disc first");
return;
};
require_disc!();
// A point light is {r,g,b,intensity} then {x,y,z,radius}, 0x20 bytes: the
// colour and intensity small, the radius positive.
let plausible = |b: &[u8]| -> bool {
let w = |k: usize| f32::from_le_bytes(b[k * 4..k * 4 + 4].try_into().unwrap());
let c = [w(0), w(1), w(2)];
let intensity = w(3);
let p = [w(4), w(5), w(6)];
let radius = w(7);
c.iter()
.chain([&intensity])
.all(|v| v.is_finite() && v.abs() < 4.0)
&& p.iter().all(|v| v.is_finite() && v.abs() < 1e4)
&& radius.is_finite()
&& radius > 0.0
&& radius < 1e4
};
for lv in 0..3usize {
let Ok(gp) = std::fs::read(data.join(format!("level{lv}/gameplay.bin"))) else {
continue;
};
let mut hits: Vec<usize> = Vec::new();
for at in (0..gp.len().saturating_sub(0x20)).step_by(4) {
if plausible(&gp[at..at + 0x20]) {
hits.push(at);
}
}
eprintln!(
"level{lv}: {} plausible 0x20 records in {} bytes",
hits.len(),
gp.len()
);
// Cluster into runs of consecutive 0x20 records.
let mut run: Vec<usize> = Vec::new();
let mut emit = |run: &mut Vec<usize>| {
if run.len() >= 4 {
eprintln!(
" run of {} at {:#x}..{:#x}",
run.len(),
run[0],
run.last().unwrap() + 0x20
);
}
run.clear();
};
for &at in &hits {
if run.last().is_some_and(|&l| at == l + 0x20) {
run.push(at);
} else {
emit(&mut run);
run.push(at);
}
}
emit(&mut run);
// And show the first record of any run of exactly eight.
let mut run: Vec<usize> = Vec::new();
for &at in &hits {
if run.last().is_some_and(|&l| at == l + 0x20) {
run.push(at);
} else {
if run.len() == 8 {
let b = &gp[at - 0x100..at];
for r in 0..8 {
let w = |k: usize| {
f32::from_le_bytes(
b[r * 0x20 + k * 4..r * 0x20 + k * 4 + 4]
.try_into()
.unwrap(),
)
};
eprintln!(
" light {r}: colour ({:.3},{:.3},{:.3}) intensity {:.3} pos ({:.1},{:.1},{:.1}) radius {:.1}",
w(0), w(1), w(2), w(3), w(4), w(5), w(6), w(7)
);
}
}
run.clear();
run.push(at);
}
}
}
}
/// Every level texture decodes to a GS TEX0 register.
///
/// The GS addresses textures by exponent, so TW and TH are `log2` of the
docs/plan/level-assets.md
+50
View File
@@ -2646,3 +2646,53 @@ That is the same mistake one level down from the section-indexing bug: I used a
decoding I had never checked to produce results, and then measured the results
with the same unverified decoding. The check existed as a tool from the first
commit.
## Camera position in EE RAM: the differential measurement
The guard-band clip test needs the camera, and the doc says so explicitly -- "both
are per-frame game state, so this needs the camera at a savestate". Two savestates
give a differential: **anything that moved between them is per-frame state**, and
anything static is not. That is the measurement, and it needs no knowledge of where
the camera lives.
Frames `.01` and `.04`, both 33,554,432 bytes. Of every 16-byte-aligned triple of
finite floats with magnitude 0.001..100,000, **2,005 differ** between the two.
Two shapes in the output, and they are clearly different things:
0x152c70 [247.000, 194.000, 49.890] -> [300.170, 227.480, 128.000]
0x188660 [251.864, 195.641, 51.895] -> [298.396, 224.011, 128.948]
0x188670 [251.864, 195.641, 51.895] -> [298.396, 224.011, 128.948]
0x188680 [251.864, 195.641, 51.895] -> [298.396, 224.011, 128.948]
0x188690 [251.864, 195.641, 51.895] -> [298.396, 224.011, 128.948]
The `0x1886xx` block repeats the same triple four times at 16-byte stride -- that
is a per-object array, not a camera. And `0x18aa70` holds
`[0.033, -0.212, 0.977] -> [0.506, 0.644, 0.574]`, a near-unit vector that reads as
a direction rather than a position.
**`0x152c70` is the interesting one** and it is only a candidate:
[247.000, 194.000, 49.890] -> [300.170, 227.480, 128.000]
Small positive coordinates in the range Aranos occupies, moving between frames, at
an address that is a singleton rather than an array element.
**Not claimed as the camera position.** 2,005 candidates is not a shortlist, and
this stretch has produced enough confident-looking numbers built on unverified
premises that the bar for saying "this is X" is an independent check, not a
plausible shape.
**What would confirm it**, in order of cheapness:
1. The same address should move *smoothly* between adjacent frames. Take `.01`,
`.02`, `.03`, `.04` and check the series is monotone-ish rather than jumping --
a camera between consecutive frames moves a little, not 50 units.
2. It should be a **singleton**: the camera is one thing, not an array. `0x152c70`
is already in a sparse region, but that needs confirming rather than assuming.
3. Perturb the camera in an emulator and watch that address alone change.
Point 3 is the decisive one and it is cheap -- it is the same technique the
lighting verification used. Points 1 and 2 need no emulator at all and run off the
savestates already on disk.