DEV Community

Nivando Soares
Nivando Soares

Posted on

Porting Test Drive II from SNES to PC, Part 21: Narrowing the static Mode 7 plateau to BG sampling

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 bg1 surface is also static
  • how much of the fixed diff box is even touched by sprites
  • whether a small horizontal bias helps the BG side enough to justify a Mode 7 coordinate 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.ppm is byte-identical
  • vram.bin is byte-identical
  • oam.bin is byte-identical
  • ppu_state.json is byte-identical
  • bg1_visible.ppm is 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-ppu with OAM vs main_visible: 2698 mismatched pixels
  • simple with OAM vs main_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 / 14839 pixels
  • 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:

  • 3982 mismatched 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: 38 rows

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 +1 improves the BG-only compare from 3982 -> 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 hscroll bias is too naive, even though it points in the right direction for the BG-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)