Porting Test Drive II from SNES to PC, Part 44: Narrowing the first rival-only blink cue
The previous checkpoint closed the first stable post-02:9016 rival-only split
as the extra top-strip OAM marker under:
$1C76 -> state_11f3 -> oam_0730
That still left one smaller visual report open:
the user said the first meaningful cue was not only the strip marker, but the
rival lights in the rearview turning on.
This checkpoint narrows that cue to a single frame step.
The right comparison was lane-local, not only rival-vs-clock
I had already compared the rival and no-opponent paths against each other over
the shared window 2048..2088.
That was enough to close the stable marker split, but not enough to isolate
the first blink.
The user suggested the correct follow-up:
compare the first two rival frames directly.
Rival frame 2048:
Rival frame 2049:
That compare is not subtle:
- rival
2048 -> 2049:117changed pixels - bbox:
(180, 11, 194, 19)
The no-opponent lane does not do the same thing at all:
- no-opponent
2048 -> 2049:0changed pixels
So this is not just a generic first-frame stabilization artifact.
It is rival-only.
What this closes, and what it does not
This checkpoint does not yet bind the blink to a fully named state field.
So I am not promoting "rearview rival lights" as a fully closed code-level
claim yet.
But it is now much tighter than before:
- the first rival-only blink cue is not somewhere in the whole
2048..2088window - it happens immediately on rival
2048 -> 2049 - it is localized to a small top-right HUD subregion
- the no-opponent lane stays pixel-identical across the same step
That is enough to redirect the next trace from "whole top strip" to one much
smaller target.
The remaining open problem is no longer where the blink first appears.
It is which rival-only OAM/state path owns that top-right activation beyond
the already-closed oam_0730 strip marker.


Top comments (0)