vwemirror/TeslaRel410
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BT410 5.3.86: colour-mapper escalation KILLED -- they read palettes, they never blit

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-30 08:04:45 -05:00
co-authored by Claude Fable 5
parent 5a465c2321
commit 902ccf1332
1 changed files with 35 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
restoration/source410/MUNGA_L4/L4GREND.NOTES.md
+35 -16
View File
@@ -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