Firestaff

DM1 placeholder and synthetic-data inventory (2026-08-07)

Systematic scan of every DM1 source path (src/dm1/, src/dm1v2/, include/dm1_*, src/engine/*.c uses of DM1 APIs) for placeholders, synthetic substitutes, host-invented pixels/fonts/palettes/strings, and capture-gated stubs. Scope excludes tests, contract-only receipts, and cross-game code. Every remaining candidate is classified below; the findings are then aggregated into the four current DM1 slices.

Scan methodology

Five ripgrep passes over src/dm1/, include/dm1_*.h:

  1. TODO|FIXME|HACK outside _XXX_ constants (ReDMCSB naming).
  2. synthetic outside suppress|reject|refuse|guard|contract-only.
  3. placeholder any occurrence.
  4. host_(font|palette|colour|color|pixel|text|render|draw).
  5. fallback outside no fallback|refuse.*fallback|reject.*fallback| suppress.*fallback.

Results triaged by opening every hit and classifying whether the code is (a) a real host synthesis, (b) a receipt/policy guard describing what is not allowed, (c) a ReDMCSB-named concept the original engine itself owns (F0098 fallback, F0151 synthetic wall outside dungeon, etc.), or (d) a diagnostic-only path already gated out of authenticated runtimes.

DM1 slice status

0. DM1 V2 compatibility helpers (src/dm1v2/)

Verdict: source-unbound presentation helpers must not draw. The scan found an inactive champion-select helper that had six host-invented class names, grid positions and fixed HP/stamina/mana values. It had no caller in the authenticated M11 render path, but could have recreated a panel from those values if called later. The helper now retains focus only, initializes no invented champion records and writes no framebuffer pixels. Its source-lock predicate is deliberately false until a live V1 champion record and the CHAMDRAW/PANEL source surfaces are bound together. This leaves the existing source-owned V1 HUD as the only pixel owner.

The same scan found a V2 footstep helper that generated random noise, decay, surface variants and echo despite the PC34 audit finding no party-footstep sound request. It now returns no sample and does not alter the caller’s audio buffer. Actual sound remains limited to the authenticated GRAPHICS.DAT SND3 event path.

The V2 damage-number helpers likewise contained a host 3×5 digit font and colour-dot renderer. Neither has an authenticated PC34 caller or source surface, so both now retain no popup state and draw nothing. Source-owned combat feedback remains unchanged.

The same source-unbound lane also contained two screen-shake implementations: one rand()-driven offset and one trauma model explicitly attributed to a GDC talk. Neither has a PC34 call route, so both now return zero displacement and the settings helper no longer shifts or darkens source pixels. This does not change real torch light: PC34 F0337/F0338 own palette selection and torch drain through the authenticated V1 light route.

The V2 weather helper was another source-unbound pixel producer: it made rain, fog, dust and drips from an LCG and fixed palette values. PC34 has no weather route in the ReDMCSB source inventory, while its real field effects are owned by the projectile and explosion draw chain. The helper therefore resets to NONE and cannot alter the source framebuffer.

The generic V2 particle core was likewise able to invent emitter parameters, LCG trajectories, RGBA values and indexed framebuffer pixels. ReDMCSB instead uses PROJEXPL.C explosion things and DUNVIEW.C bitmap/aspect composition; no generic post-process particle route was found. All emitter, direct-particle and blit APIs now fail closed without storing or drawing a particle. The VFX metadata bridge may still recognise source explosion things, but cannot turn them into a V2 overlay.

The V2 lighting module mixed the real six-entry PC34 palette threshold table with an unbound RGB light engine: local sources, random/hash flicker and 32×32 propagation. The palette bridge now retains only the exact G0040 values {99, 75, 50, 25, 1, 0} from DATA.C/PANEL.C. All local-light APIs are inert, so F0337/F0338 and the V1 palette route remain the only light owners.

The V2 creature-animation helper accepted arbitrary sprite indices and floating-point durations without a PC34 record. It is now inert. Creature aspect timing remains with GROUP.C F0179, and F0115 consumes the decoded G0219/DUNVIEW.C bitmap route.

The V2 item-render metadata formerly exposed two invented fs.v2.item.* identifiers. The empty action hand is now bound to the real PC34 C201_ICON_ACTION_ICON_EMPTY_HAND at GRAPHICS.DAT record 48, rectangle (144, 0, 16×16), under the canonical source hash. A generic floor item has no corresponding record: F0115 resolves the live Thing’s own G0209/G0219 aspect. That V2 binding now returns no material, leaving the authenticated V1 object pass as the only floor-item pixel owner.

The V2 camera controller also invented intermediate tile coordinates, a mid-turn facing change and subpixel pan offsets. ReDMCSB’s command path first mutates G0308/G0306/G0307; GAMELOOP then calls F0128 with that complete tuple, and F0128 presents the composed viewport. The local PC34 archive contains no separate camera material or verified interpolation route. The V2 controller now mirrors the accepted tuple immediately, reports zero offsets and cannot schedule completion callbacks or V2 HUD signals.

The champion-select compatibility file still retained a dead 5×5 font, host-drawn panel geometry, six invented classes and a 24-entry local roster. None was connected to a PC34 champion record. The file now contains only the four-slot focus marker consumed by the V1 click-route bridge; its two render entries remain strict no-draw while CLIKCHAM, CHAMDRAW and PANEL own the live selection and pixels.

The V2 screen-transition helper contained its own fade-to-black/fade-to-white, wipe and pixelation rules driven by local animation state. It had no caller and no PC34 media binding. ReDMCSB GAMELOOP passes the committed party tuple directly to F0128, and F0097 remains the source viewport-present entry point. The compatibility APIs now have no transition state: their apply functions copy the source framebuffer unchanged, and the V2.2 fade reports zero opacity. This preserves the source-owned viewport as the only pixel path.

The V2.0 post-process chain also contained five host transformations: CRT-row dimming, a 3×3 indexed dither mode filter, invented intermediate brightness levels, an RGBA unsharp mask and gamma/brightness/contrast compensation. These had active SDL callers, but no PC34 ownership. ReDMCSB transfers its owned palette entries directly and then presents the viewport. The four pixel filters now accept valid compatibility calls without changing a buffer, while the LUT builder copies the authenticated G9010 VGA table exactly regardless of its host adjustment arguments.

The V2 level-transition file duplicated that issue with two local animation models. It could blacken stairs, fade a pit fall, flash teleports and draw a portal mask, then separately estimate transition durations from invented tick counts. ReDMCSB instead updates map coordinates through F0150 and draws the committed party tuple through F0128. Both V2 APIs now retain no transition state, render no overlay and report no synthetic duration.

The V2 message log kept a 256-entry text cache, a locally encoded 4×5 font, category dots and a background strip. Its companion stat tracker accumulated global step, kill, item and play-time totals that do not exist as a PC34 record. ReDMCSB routes level messages through the message area and reads skills/statistics from each champion; DMWeb describes those champion-bound values. The V2 compatibility APIs now retain no log text, draw no pixels and reject global-total persistence.

1. DM1 V1 — PC 3.4 parity lane (src/dm1/*_pc34_compat.*)

Verdict: no open placeholders. DONE.md line 558-564 (2026-08-06) records the full re-audit against the real GRAPHICS.DAT/DUNGEON.DAT catalog and the DM1-ORIGINAL-REPLACE-003 … -026 inventory: “source sessions either consume an authenticated decoded surface or fail closed/no-draw.”

2026-08-07 production recheck: M11’s ordinary teleporter route uses the F0113 source plan with C076 and C070..C075 masks. The old cyan/white rectangle exists only in the non-DM1/CSB debug route. The active text route accepts M653 only at the source-owned 695 or 557 indices; when that material is unavailable, authenticated DM1 leaves text undrawn instead of using the host 5x7 font. These are production-path checks, not conclusions drawn from the synthetic contract fixtures.

2026-08-07 creature-timeline recheck: the historic M11 C04 map-scan simulator is now unreachable for an authenticated sourceId == "dm1" session. PC34 world loading enters the ReDMCSB F0882 → F0195 route, which activates the decoded groups and schedules their C37 behavior events before M11 ticks. M10’s F0190/F0209 dispatcher owns subsequent behavior. The old scan remains only for isolated diagnostic worlds, where it cannot manufacture movement or attacks in a real DM1 session.

Every candidate that survived the scan is one of:

V2 journal, minimap, and tooltip

The two V2 journals contained separate text archives and save files. The two minimap variants built explored 32×32 grids, their own party markers, and transparent pixel overlays. The tooltip also placed its own 4×5 font and a time-controlled background over the image. None of these data sets or drawing paths exists in the PC34 material.

ReDMCSB feeds the current dungeon image directly from GAMELOOP.C to F0128_DUNGEONVIEW_Draw_CPSF, then to F0097_DUNGEONVIEW_DrawViewport. Text messages pass through F0047_TEXT_MESSAGEAREA_PrintMessage. DMWeb’s description of graphics entry 562 instead documents the original text masks and the rectangle for the held item’s name. Greatstone’s PC34 register is a GRAPHICS.DAT mapfile and has no separate entry for a journal, automap, or tooltip. The APIs are therefore compatibility surfaces without saving, map cache, font, timer, or pixel drawing.

2. DM1 V2.2 — modern-presentation lane (include/dm1_v22_*)

Verdict: optional modern art remains blocked unless it is derived from the original PC34 GRAPHICS.DAT.

include/dm1_v22_finished_art_material_gate_pc34.h is a policy module that classifies each modern-art slot via a manifest. A PNG is source-backed only when its generator is exactly original_graphics_dat_10x_palette_expansion, the provenance emitted by scripts/build_dm1_v22_source_fsart.py. PBR, AI and generic review-generator labels are not game-data provenance and are treated as blocked placeholder material even if a file exists on disk. This prevents an AI-generated or hand-authored modern asset from activating the V2.2 path or contributing to a parity claim.

include/dm1_v2_asset_pipeline_pc34.h:213 warns not to use placeholder pixels when real data is available or expected — this is the policy statement, not a violation.

Source mapping available: scripts/build_dm1_v22_source_fsart.py --hero-slots emits all seven required V2.2 route IDs from the supplied PC34 archive: D3 wall 107, floor 78, pit edge 57, Demon front 657, champion-portrait atlas 26, door frame 86 and teleporter field 76. Each manifest entry retains the source record index and SHA-256 plus a rationale. The command does not install or promote the pack. The local pbr_hero/gpt-image-2 manifest remains installed but is SYNTHETIC_PLACEHOLDER (0/7 real slots), so the normal route stays on source-owned V1/V2.1 material.

3. DM1 FM Towns

Verdict: no synthetic pixels; menu rendering blocked on decoded EGB shim work.

4. Combat-log diagnostic overlay (dm1_v1_combat_log_pc34_compat.c)

Verdict: real host synthesis, but scope-gated to diagnostic worlds only.

The file defines a hardcoded 3x5 ASCII mini font at k_minifont_ascii32_126 (line 82) and a draw_text_minifont path (line 180). DM1_CombatLog_Render at line 191 has two hard gates before either path can run:

  1. DM1_CombatLog_SourceAllowsDiagnosticOverlay(state->sourceKind) at line 209 — returns early for every authenticated PC34 source.
  2. DM1_CombatLog_SourceAllowsFallbackFont(state->sourceKind) && !state->originalFontAvailable at line 219 — the fallback font path is unreachable in an authenticated session even if the original font is missing (which would already be an asset failure).

Authenticated PC34 gameplay never sees a synthesised glyph from this module. DONE.md line 539-543 (2026-08-06) records the same conclusion: “Disabled the synthetic English combat-log overlay for authenticated DM1 source sessions.”

Action: none required. The synthesis is confined to the diagnostic perimeter that the user asked to keep.

What this inventory does not count

Extended scans of the excluded categories (2026-08-06)

For completeness, the same triage was re-run against the excluded categories. Nothing found there requires a DM1 code change, but the scan is recorded so the inventory is verifiably total:

Test fixtures (tests/*dm1*, 1,516 files)

Contract-only receipts (296 files)

“stub” / “unimplemented” / “not implemented” (6 files)

ReDMCSB source-cite density

Verdict after the extended scan

The four-slice classification stands unchanged. The excluded categories either (a) exist precisely to declare “no synthesis” as policy (contract-only receipts), (b) construct synthesis on purpose to test the rejection paths (test fixtures), or (c) belong to modernization lanes that are already gated behind the finished-art material gate (V2 camera, V2.2 shapes).

Cross-references