DEV Community: Nivando Soares

TD2 Port Checkpoint: Native SDL Archaeology Demo Timeline

Nivando Soares — Fri, 03 Apr 2026 02:39:13 +0000

TD2 Port Checkpoint: Native SDL Archaeology Demo Timeline

The SDL demo path for the TD2 port is now a real native timeline instead of a
single near-static gameplay seed.

This checkpoint promotes the default launcher into an archaeology-driven demo
tour built from the raw-state artifacts already solved in the repo:

credits
attract / Mode 7 windows
menu anchors
gameplay anchors

The important constraint is what it does not do:

it does not use compare mode
it does not write PPM or PNG dumps
it does not render from screenshot playback
it does not run a ROM/CPU emulation path

The default entry point is still:

./port/run_demo.sh

But now that launcher boots a manifest-driven native timeline from:

port/assets/native_demo_archaeology_timeline.txt

Each step loads a design_pack or design_pack_range frame and renders it
through the port's SDL-native SNES-mimetic pipeline from:

raw/vram.bin
raw/cgram.bin
raw/oam.bin
raw/ppu_state.json

Where archaeology already has contiguous frame coverage, the timeline stays
exact. Where the repo only has sparse anchors, the launcher now uses explicit
infer_hold stretches instead of hiding that gap behind screenshot playback.

That makes the current capability demo honest:

exact frames stay exact
missing spans are labeled as inferred holds
the demo still moves across the best proven path in the repo

Another useful cleanup landed under the hood: in demo mode the launcher now
skips optional layers/main_visible.ppm loading entirely. That means the demo
window is no longer just "compare off" in principle; the reference surface is
out of the runtime path altogether.

The on-screen overlay now states the proof directly on top of the SDL frame:

MESEN OFF
ROM CPU EMU OFF
REFERENCE PPM OFF
PPM PNG DUMP OFF
active mode / source / callbacks / output resolution

The dedicated launcher smoke also changed accordingly. It now verifies that the
default demo:

enters timeline mode
reports the raw-only launcher contract
advances beyond the first clip under SDL_VIDEODRIVER=dummy

The full port suite still passes after the change:

make -C port test

What this checkpoint proves

It proves the current archaeology set is already strong enough to present a
moving SDL-native capability demo without falling back to PPM/PNG playback.

What it does not prove yet

It does not prove continuous runtime-owned gameplay or a full native
no-input attract loop. The next content-side job is to replace the remaining
inferred holds and sparse gameplay snapshots with denser raw-state captures or
true runtime-owned frame progression.

A measured scanline contract finally beat static composition on a late Test Drive II frame

Nivando Soares — Thu, 02 Apr 2026 00:41:59 +0000

A measured scanline contract finally beat static composition on a late Test Drive II frame

I closed a small but important runtime checkpoint on the SNES-mimetic The Duel: Test Drive II port.

The question was narrow:

For the late gameplay family around frames 3250/3400/3550, should I keep extending the static BG3 top-band composition rule, or go back to stronger measured scanline/state fields?

Today the answer stopped being speculative.

The bounded experiment

I captured one new visible-scanline trace for the promoted late-entry traffic-emergence frame 3400 and wired it into the runtime's versioned scanline-contract surface.

The route was the existing bounded braking variant, so this was not a new archaeology lane, just a tighter test on the current port path.

The key artifact is:

tools/out/lane3_live_entry_brake_frame03400_scanline_full/td2_scanline_step_test.json

And the runtime output promoted from it is:

tools/out/port_gameplay_scanline_runtime_pngs_20260401/live_entry_3400_00000.png

What changed

Before this checkpoint, frame 3400 only used the static late-gameplay composition rule:

enable BG3 only in the top band
keep BG3 > BG2 only in that same band
cutoff 79

That rule was useful, but it still treated the whole late-entry family as basically “composition-only unless proven otherwise”.

The new scanline-backed 3400 render proved otherwise.

Compared to the earlier composition-only runtime PNG for the same frame:

pixel delta between the two runtime outputs: 9309
mismatch against bg_stack_visible_support.png: 15497 -> 7649

That is not a cosmetic shuffle. It is the first late-entry proof that the current measured scanline field family actually pays off on a promoted gameplay bundle.

Why this matters

This changes the next step for the port.

The late-entry gameplay family should no longer be treated as one uniform “static composition first” lane:

3400 is now a positive proof that measured scanline fields can materially improve the runtime output
3250 stays useful as the counterexample where the current main_layers/bg1/bg2/bg3 field set is still a no-op
3550 is now the obvious next bounded follow-up

So the plan is no longer “extend static composition everywhere and maybe revisit scanlines later”.

The better plan is:

keep the composition rule where it still earns its keep,
but promote stronger measured scanline/state consumers where the evidence is already paying off,
starting from 3400 and likely testing 3550 next.

Port-facing checkpoint

The runtime smoke now validates 3400 as a real scanline-backed consumer instead of a composition-only one.

That gives the SDL port a more honest picture of late gameplay: some of these frames need more than a static horizon-strip rule, and the runtime now has one concrete proof point inside that family.

Promoting late-gameplay BG3 composition contracts in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 20:45:56 +0000

Promoting late-gameplay BG3 composition contracts in the TD2 SDL port

This checkpoint moved one late-gameplay renderer hypothesis out of tooling and into the runtime.

The late live-entry bundles at frames 3250, 3400, and 3550 already had a strong signal from the cutoff sweep: the missing horizon strip was not explained by missing assets, but by a narrow composition rule. The best candidates were consistent enough to promote:

frame 3250: enable BG3 in the top 79 scanlines and keep BG3 > BG2 there
frame 3400: same 79-line window
frame 3550: same rule with a deeper 95-line window

The runtime now loads those rules from a versioned contract file instead of a hardcoded late-gameplay lookup:

rom_analysis/docs/gameplay_composition_contracts.jsonc

On the implementation side, td2_runtime resolves the matching profile for the loaded design pack, and td2_ppu now applies two concrete knobs in the native SDL render path:

bg3_enable_top_scanlines
bg3_above_bg2_top_scanlines

That means the late-gameplay top-band BG3 rule is now a first-class part of the native renderer rather than a design-only experiment.

Validation stayed bounded and explicit:

make -C port test
python3 tools/build_docs_wiki_report.py --manifest rom_analysis/docs/wiki_doc_index.json --output-dir tools/out/docs_wiki --markdown-bundle-dir tools/out/docs_wiki_markdown_bundle

The current smoke matrix passed with:

compare lane 3/3
scheduler smoke 335 checks
input mutation smoke 200 checks
live input smoke 21 checks
scanline / composition contract smoke 39 checks

For design review, I also regenerated runtime PNGs for the promoted late-entry anchors so the team can judge the native SDL output directly, not only the sweep candidates.

The practical result is modest but important: late gameplay is now narrowed past “maybe BG3 matters here” and into one explicit, versioned composition rule that the runtime consumes. The next question is whether that same family needs more measured state beyond this top-band rule, or whether extending the composition contract to more anchors still pays off.

Sweeping late-gameplay BG3 cutoffs in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 20:25:01 +0000

Sweeping late-gameplay BG3 cutoffs in the TD2 SDL port

The previous checkpoint closed one ambiguity in the late gameplay bundles: raw BG3 was there, and it was visually meaningful. That still left the harder question open: what exact composition rule was missing?

This turn I promoted a dedicated sweep tool for one very narrow hypothesis:

BG3 above BG2 in a top band
BG3 under BG2 below that band

The new tool is tools/analyze_gameplay_bg3_cutoff.py, and it scores tracked bundle compositions against bg_stack_visible_support.png instead of relying on eyeballing alone.

I ran it against three promoted late-entry anchors:

3250
3400
3550

The result was stronger than I expected.

Best cutoffs landed at:

3250: 79
3400: 79
3550: 95

And the mixed candidate beat the tracked main.png on all three anchors.

That matters because it narrows the renderer problem again. The next useful question is not “should we somehow use more BG3?” and it is not “are the assets incomplete?”. The next useful question is whether late gameplay needs a top-band BG3 > BG2 precedence rule, likely with a slightly deeper band on the later collision-heavy 3550 phase.

This is exactly the kind of result I want from the archaeology/tooling loop:

define one falsifiable renderer rule
score it against tracked artifacts
promote PNGs the design team can inspect
reduce the search space for the native SDL renderer

Promoted artifacts from this checkpoint include:

tools/out/gameplay_bg3_cutoff_sweep_20260401/summary.md
tools/out/gameplay_bg3_cutoff_sweep_20260401/lane3_live_entry_frame03250_bundle_bg3_cutoff_candidate.png
tools/out/gameplay_bg3_cutoff_sweep_20260401/lane3_live_entry_brake_traffic_frame03400_bundle_bg3_cutoff_candidate.png
tools/out/gameplay_bg3_cutoff_sweep_20260401/lane3_live_entry_frame03550_bundle_bg3_cutoff_candidate.png

The next step is straightforward: either promote this as a measured late-gameplay contract surface first, or translate it into a native renderer rule and let the compare lane decide if it survives contact with the real frame stack.

Promoting raw BG3 gameplay bundle previews in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 20:10:44 +0000

Promoting raw BG3 gameplay bundle previews in the TD2 SDL port

Today's checkpoint was small in code size but important in interpretation.

The late gameplay bundles in the project already had useful BG1, BG2, OBJ, and screenshot-derived support surfaces, but they were still weak on one practical question: when design flagged the sky/horizon side of gameplay, were we looking at a missing asset, or were we looking at a composition problem?

I closed that ambiguity by extending the gameplay bundle builder to emit first-class BG3 artifacts next to the existing layer outputs:

bg3.ppm
bg3.png
bg3_render.json

Then I refreshed the promoted late-entry bundles for frames 3250, 3400, and 3550.

The useful result is that raw BG3 is clearly populated on these anchors. It carries the sky-to-horizon helper strip much more directly than BG2, which means the next renderer question is no longer "does this bundle even have usable BG3?". The next question is "which gating/composition rule makes that helper layer visible in the final frame?"

That sounds subtle, but it matters a lot for a faithful SNES-style port. It keeps the team from wasting time chasing asset extraction that is already good enough, and it gives design a tracked PNG surface for the exact layer that appears to carry the late gameplay horizon helper.

Promoted artifacts from this checkpoint:

tools/out/lane3_live_entry_frame03250_bundle/bg3.png
tools/out/lane3_live_entry_brake_traffic_frame03400_bundle/bg3.png
tools/out/lane3_live_entry_frame03550_bundle/bg3.png

The code change itself lives in tools/build_gameplay_frame_bundle.py, and the lane-3 notes were updated so the new BG3 surfaces are part of the documented review workflow.

That is the kind of progress I want more often in this port: narrow the uncertainty, promote the artifact, and make the next renderer step smaller and more defensible.

Versioning gameplay scanline contracts in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 19:51:47 +0000

Versioning gameplay scanline contracts in the TD2 SDL port

This checkpoint moves one of the gameplay renderer shortcuts into a cleaner shape.

Until now, the SDL runtime loaded the live-race scanline overlay through one scene-specific path. That was enough to prove the horizon fix on the promoted gameplay_live_race_mid bundle, but it was not a good long-term surface for more gameplay phases.

So I replaced that hardcoded lookup with a versioned contract:

rom_analysis/docs/gameplay_scanline_contracts.jsonc

The runtime now selects scanline overlays from that contract, and the tracked sources behind it currently are:

tools/out/lane3_live_race_mid_scanline_full/td2_scanline_step_test.json
tools/out/lane3_live_entry_frame03250_scanline_full/td2_scanline_step_test.json

The contract still uses a deliberately narrow field set:

main_layers
bg1_hscroll/bg1_vscroll
bg2_hscroll/bg2_vscroll
bg3_hscroll/bg3_vscroll

That is enough to keep the first solved gameplay consumer intact. The live-race bundle still renders with the restored sky / mountain / roadside split, and that stays protected by the new test_scanline_contract.sh smoke.

The more interesting part of this checkpoint is the second gameplay consumer.

I promoted tools/out/lane3_live_entry_frame03250_bundle/design_pack onto the same contract-backed surface and captured a full 224-scanline trace for it. That closes a useful architectural question: later gameplay bundles can now opt into the same scanline path without needing another runtime special case.

But it also closed a stronger negative result.

When I compared the 3250 runtime output with and without the new scanline contract, the result was still:

0 mismatched pixels

That means the second gameplay phase is not blocked on trace plumbing anymore. It is blocked on missing renderer inputs beyond the current field set. In other words, scrolls plus main_layers were enough for the first live-race fix, but they are not enough for the later live-entry phase.

That is exactly the kind of boundary I wanted from this step: less ad hoc code, one versioned path for gameplay scanlines, and a clearer definition of what the next renderer promotion actually has to solve.

Restoring gameplay scanline depth in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 19:37:04 +0000

Restoring gameplay scanline depth in the TD2 SDL port

This checkpoint closed a very specific visual bug in the SDL reimplementation of The Duel: Test Drive II.

The promoted gameplay rail gameplay_live_race_mid was still rendering from a flat end-of-frame ppu_state, which made the road swallow the shoulders and the horizon. That was good enough for early archaeology, but not for a faithful SNES-mimetic port.

The fix was to stop treating that gameplay seed as one global presentation state. I attached the measured visible-scanline profile from tools/out/lane3_live_race_mid_scanline_full/td2_scanline_step_test.json directly to the promoted rail and fed these fields into the native SDL renderer:

main_layers
bg1_hscroll/bg1_vscroll
bg2_hscroll/bg2_vscroll
bg3_hscroll/bg3_vscroll

That immediately restored the first-order depth cues on the live-race frame: the horizon comes back, BG3 only re-enters on the measured strip, and BG2 uses the real per-scanline staircase instead of one global VOFS.

The useful part is that this did not require inventing a new gameplay heuristic. The scheduler rail stayed intact; the improvement came from consuming the trace we already had in a more faithful way.

I also kept the guardrails cheap:

make -C port test still passes end to end
test_scheduler.sh now proves that the scanline profile is loaded for gameplay_live_race_mid
the same smoke also checks a few framebuffer pixels so the restored sky/mountain/grass split does not silently regress

There is still a clear boundary here: only the promoted live-race rail is scanline-aware today. The next step is to move this attachment into versioned contract data and promote another gameplay phase on the same path instead of letting later bundles fall back to flat presentation.

Promoting the measured 2052..2088 menu window in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 18:41:13 +0000

Promoting the measured `2052..2088` menu window in the TD2 SDL port

This checkpoint closes a useful gap in the SDL runtime: the menu_gameplay_entry rail no longer jumps from a handful of sampled post-2050 anchors. It now carries the exact measured baseline window from frames 2052..2088, and the default-rival A lane replays that same window with measured state mutations instead of guessed interpolation.

The practical change is in the scheduler and mutator surface. The runtime now loads every measured baseline frame in that bounded window from scheduler_rail_contracts.jsonc, and the A route mutator applies the traced state_09a2/state_09a8/state_137c plus dp_0020/dp_0022/dp_0053/dp_0054 values for the same corridor. That makes the menu rail much harder to drift silently: it is no longer “five anchors and some hope”, it is a concrete measured sequence.

The probe data justified that promotion. Inside 2054..2088, the no-input lane is stable enough to treat as exact contract data, while the A lane forms a real staircase: dp_0053/dp_0054 advance frame by frame, dp_0020 only flips on selected even frames, and state_09a8 only flips on part of the odd-frame cadence. That is exactly the kind of bounded, deterministic window that is worth promoting verbatim before trying to generalize anything.

Validation stayed clean after the expansion:

scheduler smoke: 320/320
input mutation smoke: 200/200
compare lane: 3/3
regression lane: 2/2

For design review, the runtime is still emitting PNG alongside the native PPM dumps, and this checkpoint also materialized a local paired A/B PNG pack for frames 2054, 2066, 2083, and 2088 so the team can track the corridor visually as the runtime evolves.

The next gate is straightforward now: stop hand-feeding this through --input-script only and wire live SDL keyboard/controller input into the same mutator path. The measured menu window is doing its job; the right next move is to make the runtime consume real input on top of it.

Measured post-2050 input anchors and PNG review artifacts for the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 17:53:14 +0000

Measured post-2050 input anchors and PNG review artifacts for the TD2 SDL port

The current TD2 SDL runtime already had scripted input and a first menu handoff mutator, but it still flattened the post-2050 default-rival corridor into a mostly generic rail.

This checkpoint moves one step deeper into a SNES-mimetic path:

promoted exact no-input scheduler anchors at frames 2052, 2053, 2083, 2104, and 2125
overlaid the traced default-rival A route on top of those anchors
carried measured fields instead of heuristics: state_09a2, state_09a8, state_137c, dp_0020, dp_0022, dp_0053, and dp_0054
taught the runtime dump path to emit PNG siblings for every PPM artifact, including compare outputs

The useful practical effect is twofold.

First, the port now has a grounded post-2050 mutation surface that is tied directly to probe evidence instead of broad guessed gameplay logic. Second, the same runtime artifacts that validate the port are now immediately usable by design review without manual conversion.

Validation stayed bounded and green:

make -C port test
PNG sanity check against the existing PPM dump path: 0 mismatched pixels on the frame-300 smoke
local review pack exported for the new anchor frames under tools/out/port_input_mutation_anchor_pngs_20260401/

This is still not a full continuous gameplay model. The next step is to densify these exact anchors into short windows, especially around the 2054..2088 dashboard/radar divergence, and then feed live SDL input into the same mutator surface.

Adding Scripted Input Mutation to the TD2 SDL Runtime

Nivando Soares — Wed, 01 Apr 2026 17:29:29 +0000

Adding Scripted Input Mutation to the TD2 SDL Runtime

The last checkpoint externalized the non-intro scheduler rails into versioned contracts. That closed the hardcoded-anchor problem, but the runtime was still fundamentally input-blind.

This checkpoint adds the first real input surface on top of those rails.

What changed

There is now a shared input module in the port runtime:

td2_input.*

It parses the same window syntax already used by the Mesen-side tooling:

frame:buttons
start-end:buttons

with button tokens like:

a
b
start
up
down
left
right

The SDL runtime now accepts that through:

--input-script

So a headless run can do things like:

./port/build/td2_port \
  --scene-dir tools/out/design_lane3_live_race_mid_frame0_native \
  --scheduler-profile gameplay_live_race_mid \
  --input-script '3:a' \
  --headless \
  --frames 1

First promoted mutations

The new layer is intentionally narrow and grounded.

1. `JOY1` sample in runtime state

Current active buttons now mirror into state_0960, which the archaeology already treats as the JOY1 sample copied during NMI.

That means the runtime is no longer just replaying callback/state rows. It now has a direct input-facing field that changes under scripted input.

2. Traced no-opponent menu route

The menu_gameplay_entry rail now also recognizes the traced no-opponent corridor:

right+down
then confirm

When that route is present in the input history, the downstream handoff flips from the default rival baseline:

$1C70 = 0
$1C76 = 1

to the no-opponent state:

$1C70 = 3
$1C76 = 0

This is the first input-driven semantic branch promoted directly into the runtime.

Validation

I added a new smoke:

./port/test_input_mutation.sh

Current pass surface:

gameplay A -> state_0960 = 0x0080
gameplay B -> state_0960 = 0x8000
gameplay right+down -> state_0960 = 0x0500
menu no-opponent route -> downstream $1C70 = 3 / $1C76 = 0

The full port test suite stayed green after that.

Why this matters

This is not full gameplay input emulation yet. But it is an important boundary crossing.

The runtime now has:

contract-fed rails
a reusable scripted input surface
a first direct input mirror
a first traced route mutation that changes semantic state instead of just frame selection

The next step is to extend that layer into the post-2050 gameplay deltas that are already narrowed in the archaeology, especially fields like state_09a2, state_09a8, dp_0053, and dp_0054.

Contract-Fed Scheduler Rails for the TD2 SDL Port

Nivando Soares — Wed, 01 Apr 2026 15:29:44 +0000

Contract-Fed Scheduler Rails for the TD2 SDL Port

This checkpoint closes an important bootstrap gap in the SDL port.

The runtime already had three promoted scheduler rails:

intro_noinput
menu_gameplay_entry
gameplay_live_race_mid

But two of them were still encoded as hardcoded C branches. That was good enough to prove the path, but not good enough to treat the rails as reusable contracts.

What changed

The non-intro rails now load from a shared contract file:

rom_analysis/docs/scheduler_rail_contracts.jsonc

That file carries the validated frame windows for:

the menu handoff corridor from 1500 -> 2050
the reproducible gameplay seed over 0 -> 11

So td2_scheduler no longer needs embedded anchor tables for menu/gameplay playback. The runtime still uses the callback model for intro, but menu and gameplay now come from versioned contract data.

I also tightened the scheduler smoke so it proves more than field values. It now asserts:

scheduler.contract_loaded
segment_count
scheduler_contract as the live state source

That pushes the smoke from 156 checks to 175, while keeping the same three rails green.

Wiki automation fix

The second part of the checkpoint is operational, but it matters.

The repo already had a post-push wrapper that rebuilt the curated docs wiki. The old safety rule was to skip the wiki auto-commit whenever the main worktree had unrelated dirty files. That avoided mixing work, but it also meant the wiki was often left stale.

The wrapper now rebuilds the wiki in a temporary isolated git worktree at the pushed checkpoint. If the generated wiki changes, the follow-up refresh commit is created and pushed from there.

That means:

unrelated local dirty files no longer block wiki publication
the wiki refresh commit stays isolated
local generated wiki output can be cleaned back to the pushed state afterward

Why this matters

This is still bootstrap infrastructure, not full gameplay execution. But it moves the port in the right direction:

runtime rails are becoming data-backed instead of branch-backed
validation is proving source and handoff shape, not just static values
the docs/wiki side is finally reliable enough to keep up with the checkpoint flow

The next step is not more rail hardcoding. The next step is mutating menu_gameplay_entry and gameplay_live_race_mid under real input on top of these contracts.

From seeded state to scheduler rails in the TD2 SDL port

Nivando Soares — Wed, 01 Apr 2026 14:56:55 +0000

From Seeded State To Scheduler Rails In The TD2 SDL Port

The latest checkpoint on the Test Drive II SNES port closes an important architectural gap.

Up to this point, the SDL runtime could load design packs, seed SNES-like state, render natively from VRAM/CGRAM/OAM/PPU, and compare itself against trusted extracted frames. That was a good bootstrap, but it still depended on a seeded callback shadow for the semantic side.

This checkpoint promotes a minimal callback scheduler into the runtime.

What changed:

the runtime now resolves scheduler profiles instead of seeding callback state only once at init
the first three promoted rails are now executable in the SDL port:
- intro_noinput
- menu_gameplay_entry
- gameplay_live_race_mid
the intro rail now carries the validated handoff from 01:9FE5 into 00:8029 through the 986 -> 1117 window
the menu rail now covers the input-driven corridor from 1500 -> 2050
the gameplay rail now covers the reproducible live-race seed over the promoted 3 -> 11 window

I also fixed a practical blocker in the content pipeline: tracked investigation bundles without layers/main_visible.ppm can now load directly in the runtime as long as compare is not requested. That matters because the most useful menu/gameplay design packs are often raw-state bundles first and compare goldens later.

Validation for this checkpoint is intentionally cheap and explicit:

make -C port test
regression smoke still passes
compare lane still passes on the promoted intro fixtures
intro callback model smoke passes
new scheduler smoke passes across intro, menu, and gameplay rails

The important part is not that the scheduler is complete. It is that the port is no longer locked into intro-only seeded playback. The same runtime loop now has a viable proving path on menu and gameplay surfaces, which is where the next input and ownership work should happen.

DEV Community: Nivando Soares

TD2 Port Checkpoint: Native SDL Archaeology Demo Timeline

TD2 Port Checkpoint: Native SDL Archaeology Demo Timeline

What this checkpoint proves

What it does not prove yet

A measured scanline contract finally beat static composition on a late Test Drive II frame

A measured scanline contract finally beat static composition on a late Test Drive II frame

The bounded experiment

What changed

Why this matters

Port-facing checkpoint

Promoting late-gameplay BG3 composition contracts in the TD2 SDL port

Promoting late-gameplay BG3 composition contracts in the TD2 SDL port

Sweeping late-gameplay BG3 cutoffs in the TD2 SDL port

Sweeping late-gameplay BG3 cutoffs in the TD2 SDL port

Promoting raw BG3 gameplay bundle previews in the TD2 SDL port

Promoting raw BG3 gameplay bundle previews in the TD2 SDL port

Versioning gameplay scanline contracts in the TD2 SDL port

Versioning gameplay scanline contracts in the TD2 SDL port

Restoring gameplay scanline depth in the TD2 SDL port

Restoring gameplay scanline depth in the TD2 SDL port

Promoting the measured 2052..2088 menu window in the TD2 SDL port

Promoting the measured 2052..2088 menu window in the TD2 SDL port

Measured post-2050 input anchors and PNG review artifacts for the TD2 SDL port

Measured post-2050 input anchors and PNG review artifacts for the TD2 SDL port

Adding Scripted Input Mutation to the TD2 SDL Runtime

Adding Scripted Input Mutation to the TD2 SDL Runtime

What changed

First promoted mutations

1. JOY1 sample in runtime state

2. Traced no-opponent menu route

Validation

Why this matters

Contract-Fed Scheduler Rails for the TD2 SDL Port

Contract-Fed Scheduler Rails for the TD2 SDL Port

What changed

Wiki automation fix

Why this matters

From seeded state to scheduler rails in the TD2 SDL port

From Seeded State To Scheduler Rails In The TD2 SDL Port

Promoting the measured `2052..2088` menu window in the TD2 SDL port

1. `JOY1` sample in runtime state