Porting Test Drive II from SNES to PC, Part 21: Narrowing the static Mode 7 plateau to BG sampling
The previous checkpoint closed the late attract continuation through frame 1117.
That was useful, but it still left one stubborn question open:
if the tail was already one stable scene, was the remaining renderer gap really an object problem, or was it a Mode 7/BG problem wearing an object-shaped costume?
This checkpoint makes that distinction much sharper.
The new helper
I promoted a dedicated builder for the static tail:
tools/build_mode7_plateau_analysis.py
It takes the existing compare summary plus the matching design-pack frames and produces one canonical read of the plateau:
- which frames are really one static scene
- whether the extracted visible
bg1surface is also static - how much of the fixed diff box is even touched by sprites
- whether a small horizontal bias helps the
BGside enough to justify aMode 7coordinate investigation
That matters because this lane is no longer about broad ownership archaeology.
It is about not wasting time on the wrong subsystem.
The canonical plateau
The helper auto-collapsed the tail to one canonical plateau:
1105..1117
That is not just "same mismatch count."
Across that whole block:
-
main_visible.ppmis byte-identical -
vram.binis byte-identical -
oam.binis byte-identical -
ppu_state.jsonis byte-identical -
bg1_visible.ppmis also byte-identical
So this is a real static scene for geometry and layout purposes.
The important negative result
The old object sanity check still holds:
-
mode7-ppuwith OAM vsmain_visible:2698mismatched pixels -
simplewith OAM vsmain_visible:2698 - no-OAM vs
main_visible:9717
Objects are clearly needed.
But the new plateau analysis shows why "objects are involved" is still the wrong frontier.
The shared late diff box is:
24,68 -> 232,138
Only 4 visible sprites touch that box at all.
Their combined coverage inside the box is only:
-
128 / 14839pixels 0.862592%
That is the key narrowing.
The remaining plateau is not primarily a sprite-coverage problem.
The BG-only read
Treating frame 1105 as the canonical scene, I compared the no-OAM render directly against the extracted visible bg1 layer.
That result is:
-
3982mismatched pixels - diff box
24,67 -> 232,138
So the BG-only mismatch lives in almost the exact same box as the full plateau, only one row taller at the top.
That is a much stronger read than "the full frame is still wrong somehow."
Now the error surface is mostly one Mode 7/BG1 band.
The horizontal-bias clue
I ran two very small experiments on that canonical BG-only box.
First, a pure horizontal shift scan on the rendered BG:
- zero shift:
3982 - best whole-box shift:
-1 - best-shift mismatch:
3611
And the per-row best-shift counts still cluster around that same bias:
-
-1:38rows
That says there is a real horizontal sampling clue here, but it is not a perfect rigid translation.
Second, I tested actual Mode 7 state perturbations by changing ppu.mode7.hscroll on the canonical frame:
- base
hscroll = 0 -
hscroll +1improves theBG-only compare from3982 -> 3613
That is important because it reproduces most of the gain from the artificial shift scan with a real Mode 7 input term.
But the same perturbation does not fix the full scene:
- full-scene compare gets worse:
2698 -> 2780
So hscroll +1 is not the answer.
It is a clue.
What changed in the reading
Before this checkpoint, the safe read was:
- the late tail is one static renderer/composition plateau
After this checkpoint, the sharper read is:
- the plateau is overwhelmingly
BG/Mode 7-driven, not sprite-driven - the remaining bug is probably in horizontal sampling, rounding, or edge semantics
- a raw global
hscrollbias is too naive, even though it points in the right direction for theBG-only surface
That is a much better next step.
Instead of spending more time on hidden uploads, callback forks, or object ownership, I can now ask a narrower question:
which Mode 7 coordinate term or edge rule produces the BG-only gain without making the full-scene compare worse?
That is the next frontier for this attract plateau.
Top comments (0)