Porting Test Drive II from SNES to PC, Part 42: Fixing the post-02:9016 review-pack alignment

The previous checkpoint tried to build a human-review pack for the first shared
post-02:9016 window of the default-rival and no-opponent paths.

That pack was not good enough to review.

The user caught the problem immediately:

the screenshots did not line up with the intended gameplay-facing window.

This checkpoint fixes that instead of pretending the bad pack was still useful.

Two separate alignment bugs were hiding inside the review flow

The first bug was in validation/mesen_capture.lua.

The capture runner only applied TD2_CAPTURE_INPUT_WINDOWS while the script was
inside its explicit screenshot phase.

That meant long power-on captures silently dropped the early start,
right+down, and later confirm inputs that were supposed to happen during the
warmup.

The second bug was more subtle.

mesen_probe_boot.lua can drive callback-relative inputs through
TD2_BOOT_PROBE_TRIGGER_INPUT_WINDOWS, but that only works if the trace window
starts early enough to see the trigger callback in the first place.

If TD2_BOOT_PROBE_TRACE_START_FRAME defaults to the screenshot frame, the
probe only learns exec_point_trace.first_frames too late for the relative
inputs to fire.

So the old pack was wrong for two reasons:

• the capture path missed warmup inputs
• the first sanity probe for the no-opponent lane initially traced 01:C1D2 too late

The corrected review window starts at frame 2048, not 2044

Once the probe trace window was opened correctly, the no-opponent path landed
back on the already-documented timing:

• 01:C1D2 first hit at 1628
• 01:BE43 first hit at 1713
• L008B87 at 1736
• active_main = 02:9016 at 2044

But the screenshot at frame 2044 was still fully black.

So 2044 is a valid state anchor, but not a useful human-review surface.

The corrected screenshot packs now start at frame 2048 and cover
2048..2088, sampled every 4 frames.

Default-rival frame 2048:

No-opponent clock frame 2048:

The first stable visible delta is already on-screen

After the pack was rebuilt, I compared every sampled pair in the corrected
window.

The result is now much tighter than the old “please inspect these screenshots”
state.

The earliest stable rival-vs-clock difference is already present at frame
2048, and every sampled difference in 2048..2088 stays inside the same
top-strip bounding box:

• bounding box: (11, 11, 194, 21)
• differing pixels per sampled frame: 125..137

The corresponding diff image is tiny and very local:

The practical read is straightforward:

the default-rival lane carries an extra red radar/opponent marker in the top
HUD strip that is absent from the no-opponent lane, while the lower cockpit
surface remains visually matched in this first corrected window.

That is a much better problem statement than the previous one.

The open question is no longer:

"is there any visible divergence after 02:9016?"

It is now:

"which of the already-narrowed state fields drives this top-radar split?"

Why this is a real checkpoint

This was not housekeeping.

It changed the active lane in a concrete way:

• the broken review pack is gone
• the corrected window is pinned to a real non-black gameplay surface
• the first visible divergence is no longer generic; it is localized to the top radar strip

That means the next pass can stop guessing at whole-screen differences and
start tying the top-strip delta back to the remaining WRAM split:

• 09A2
• 09A8
• 0020/0022
• 0053/0054

The next checkpoint should now connect those fields to the recovered radar
marker behavior instead of spending more time proving that the two lanes are
different at all.