From 902ccf13328f25cb5ff3d1b836a09eecb0b53f72 Mon Sep 17 00:00:00 2001 From: Cyd Date: Thu, 30 Jul 2026 08:04:45 -0500 Subject: [PATCH] BT410 5.3.86: colour-mapper escalation KILLED -- they read palettes, they never blit 5.3.85 raised a hypothesis and explicitly flagged it as unverified: the 1345 colour-mapper entries (656 cmCrit, 662 cmHeat, 27 cmArmor) all sit on port 0, their mode is ModeSecondaryCritical, and they name adpal.pcc / adpal2.pcc / heatpal.pcc -- three files the art sweep flags, with ADPAL and ADPAL2 being 2x5 and ENTIRELY index 99. If those pixels were blitted as colour indices, 1345 widgets would each be writing out-of-range on the six-bit head, which would dwarf the 676px bar and would fire in-mission, exactly where the operator sees the artifact. Read the implementation. It does not happen. ColorMapper::ColorMapper (BTL4GAUG.CPP:389) takes the two names into the palette8Bin -- not a pixelmap bin, not a bitmap bin -- and the execute path (:526) is Palette8 *palette = warehouse->palette8Bin.GetIfAlreadyExists(...); PaletteTriplet &entry = palette->Color[currentColorIndex]; ... graphicsPort->SetColor(&entry, colorSlot); It reads the file's VGA PALETTE, lifts one RGB triple, and pushes it into a hardware colour slot. No pixel of ADPAL ever reaches a framebuffer, so its index-99 content cannot matter. The palette PAIR is a flash toggle (paletteToggle alternates per frame), which is also what twoColorMode's name comparison is for. NEGATIVE. Recorded as a closed hypothesis rather than deleted, so it does not get re-raised the next time somebody greps the sweep and sees ADPAL at 100% out-of-range. What this leaves: the in-mission exposure, if there is one, is NOT the mappers. The *CRIT/*HEAT silhouettes still carry 1500-2500px of index 231 each, and which widget blits them is still unestablished. The boot cockpit does not draw them, which is why it lights only 1030 pixels. Co-Authored-By: Claude Fable 5 --- .../source410/MUNGA_L4/L4GREND.NOTES.md | 51 +++++++++++++------ 1 file changed, 35 insertions(+), 16 deletions(-) diff --git a/restoration/source410/MUNGA_L4/L4GREND.NOTES.md b/restoration/source410/MUNGA_L4/L4GREND.NOTES.md index 2e159476..c4b096e6 100644 --- a/restoration/source410/MUNGA_L4/L4GREND.NOTES.md +++ b/restoration/source410/MUNGA_L4/L4GREND.NOTES.md @@ -75,24 +75,43 @@ out: it is an inert stub returning NULL, so `recoloredMech` never blits in our build. Unattributed. The fix covers it either way, since it zeroes the whole tail regardless of who indexes it. -**The colour mappers may be a second exposure, in-mission.** `L4GAUGE.CFG` -carries **1345** colour-mapper entries — 656 `cmCrit`, 662 `cmHeat`, 27 -`cmArmor` — and `BT_VIS_LOG` puts all of them on **port 0**, the six-bit head, -at 50,0. Their mode is literally `ModeSecondaryCritical`. They name -`adpal.pcc`, `adpal2.pcc`, `heatpal.pcc`, `heatpal2.pcc`, three of which the -sweep flags as out-of-range (`ADPAL`/`ADPAL2` are 2×5 and **entirely** index -99; `HEATPAL` has one pixel at 100). +That the boot cockpit lights only 1030 pixels says the avatar art is not being +drawn on that screen. It does not say anything about a live mission — the +`*CRIT`/`*HEAT` silhouettes carry 1500–2500 pixels of index 231 apiece, so if +something blits them on port 0 the in-mission artifact is several times the +size of the bar. Which widget blits them is not yet established. -Whether that matters depends on something not yet established: these are tiny -swatch files, and a colour mapper plausibly reads their **VGA palette** rather -than blitting their pixels. Do not repeat this as a finding until someone has -read the mapper's implementation. It is recorded because if the pixels *are* -used as colour indices, every one of 1345 mappers writes an out-of-range index -on the six-bit head — which would dwarf the 676px bar and would fire -in-mission, matching where the operator sees the artifact. +## Closed hypothesis: the colour mappers are NOT a second exposure -That the boot cockpit lights only 1030 pixels says the avatar/mapper art is not -being drawn on that screen. It does not say anything about a live mission. +Recorded because it was raised as a serious escalation and then killed, and the +kill is worth keeping so nobody re-raises it. + +The worry: `L4GAUGE.CFG` carries **1345** colour-mapper entries — 656 `cmCrit`, +662 `cmHeat`, 27 `cmArmor` — `BT_VIS_LOG` puts every one of them on **port 0**, +their mode is literally `ModeSecondaryCritical`, and they name `adpal.pcc`, +`adpal2.pcc`, `heatpal.pcc`, three of which the sweep flags (`ADPAL`/`ADPAL2` +are 2×5 and **entirely** index 99). If those pixels were blitted as colour +indices, 1345 widgets would each be writing out-of-range on the six-bit head. + +They are not blitted. `ColorMapper::ColorMapper` (`BTL4GAUG.CPP:389`) takes the +two names into the **`palette8Bin`**, not a pixelmap or bitmap bin, and the +execute path (`:526`) is + +```c +Palette8 *palette = warehouse->palette8Bin.GetIfAlreadyExists(paletteName[paletteToggle]); +PaletteTriplet &entry = palette->Color[currentColorIndex]; +... +graphicsPort->SetColor(&entry, colorSlot); +``` + +It reads the file's **VGA palette**, takes one RGB triple, and pushes it into a +hardware colour slot. No pixel of `ADPAL` ever reaches a framebuffer, so their +index-99 content is irrelevant. The two-palette pair is a flash/toggle +(`paletteToggle` alternating each frame), which is also why `twoColorMode` +compares the two names. + +**Conclusion: negative.** The mappers are not an exposure, and the search for +the in-mission source has to go elsewhere. ## A shipped data bug, found in passing — do NOT fix