Glass cockpit: per-display windows (BT_GLASS_PANELS)

Break the desktop glass cockpit's secondary displays out of the single
combined pad panel + D3D gauge strip into ONE window per pod display, each
carrying that display's surface with its RIO button bank, arranged
pod-faithfully around the main view.  New TU engine/MUNGA_L4/L4GLASSWIN.*
(BT_GLASS-only), selected by the -platform glass preset via the new runtime
gate BT_GLASS_PANELS (=0 falls back to the legacy single panel + dock).

- Surfaces are CPU-expanded from the shared gauge buffer
  (SVGA16::ExpandPlaneToBGRA, no D3D) and StretchDIBits'd in -- the D3D
  dev-composite path (dock / window / overlay) stands down while active.
- Buttons sit UNDER the imagery: big hidden click targets that reach into
  the display, with only a small protruding edge showing as a lamp light.
  Red MFD banks tile the top/bottom; radar rails run the sides + a bottom
  row; a Flight Controls window hosts the no-display banks.
- Windows: Heat / Engineering / Comm / Left Weapons / Right Weapons / radar
  + Flight Controls; edge-to-edge (no in-client margin/title; OS caption
  labels each).
- Fix blank surfaces: application/ghWnd are duplicate-defined and bind
  non-deterministically under /FORCE, so the fresh L4GLASSWIN TU read NULL.
  Reach the renderer/window via BTResolveGaugeRenderer/BTResolveMainWindow
  defined in btl4main.cpp off the real btl4App/hWnd pointers.  New gotcha:
  reconstruction-gotchas.md S6 duplicate-GLOBAL corollary.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

context/glass-cockpit.md

@@ -18,7 +18,7 @@ every trade-off.
 
 | Gate | Default | Adds |
 |---|---|---|
-| `BT_GLASS` | OFF | PadRIO input (XInput+keyboard), on-screen cockpit button panel, desktop plasma window, `glass` platform preset, miniconsole mission launcher |
+| `BT_GLASS` | OFF | PadRIO input (XInput+keyboard), per-display cockpit windows (or the legacy single button panel), desktop plasma window, `glass` platform preset, miniconsole mission launcher |
 | `BT_STEAM` | OFF (requires `BT_GLASS`) | Steam transport (`ISteamNetworkingSockets`) + `ISteamMatchmaking` lobby |
 
 - A **no-flags configure is the pure pod game** — the build of record. `cmake` options are
@@ -85,6 +85,34 @@ copied from them.
   unbound keys keep their authentic meanings (5/z presets, t-o pilot select, +/- zoom).
   In BAS control mode the pod turns with the STICK (Q/E) and pedals are inactive — authentic;
   A/D turn in MID/ADV. Full audit + census: `docs/GLASS_COCKPIT.md` §2026-07-20.
+- **Per-display cockpit windows (`BT_GLASS_PANELS`): DONE 2026-07-20 [T2 startup-verified].**
+  The `-platform glass` preset now breaks the secondary displays out of the single combined
+  panel/strip into ONE desktop window PER pod display, each carrying that display's surface
+  WITH its RIO button bank placed around it, arranged pod-faithfully around the main view
+  (`engine/MUNGA_L4/L4GLASSWIN.*`, new TU). Windows: **Heat (UL) / Mfd2 (UC) / Comm (UR) /
+  Mfd1 (LL) / Mfd3 (LR)** each with 8 RED MFD buttons split 4 above / 4 below the surface;
+  **Secondary/Radar** (portrait `sec`) with the 12 YELLOW Secondary buttons split left/right;
+  a **Flight Controls** window for the no-display banks (throttle 0x38-3F, joystick/fire
+  0x40-47, panic). Each window is a GDI window (like [[gauges-hud]]'s pad panel + the plasma
+  window) — the surface is CPU-expanded from the shared gauge buffer
+  (`SVGA16::ExpandPlaneToBGRA`, no D3D) and `StretchDIBits`'d in, so the **whole D3D
+  dev-composite path (dock / separate window / overlay) stands down** while these are up
+  (`BTDrawGaugeInset`/`BTGaugeWindowRenderAndPresent` early-return; no `gBTGaugeDockBottom`
+  strip). Runtime gate **`BT_GLASS_PANELS`** (default ON under `-platform glass`, `=0` falls
+  back to the single pad panel + docked gauges) — read by `L4PADRIO` (which panel to create),
+  `L4VB16` (suppress compositing), and `btl4main` (skip the world-window dock strip). The
+  display↔bank map (spine of the feature): Heat 0x28-2F, Mfd2 0x20-27, Comm 0x30-37,
+  Mfd1 0x08-0F, Mfd3 0x00-07, sec 0x10-1B ([[pod-hardware]] §Bank→MFD). Verified: build +
+  bounded glass launch — `[glasswin] per-display cockpit up (7 windows…)`, no crash, full
+  mission loop un-regressed; surfaces carry LIVE gauge content (`BT_GLASS_LOG` = per-surface
+  resolve/pixel diagnostic). Layout constants (surface sizes, exact button sub-positions,
+  yellow left/right split) are marked tunable in `L4GLASSWIN.cpp`. Detail: `docs/GLASS_COCKPIT.md`.
+  ⚠ **Bug found + fixed during bring-up:** surfaces were blank because `application`/`ghWnd` are
+  duplicate-defined globals that bind non-deterministically under `/FORCE` — the fresh
+  `L4GLASSWIN` TU read `application == NULL` → gauge renderer NULL. Fix: reach the
+  renderer/window via `BTResolveGaugeRenderer()`/`BTResolveMainWindow()`, DEFINED in
+  `game/btl4main.cpp` off its real `btl4App`/`hWnd` pointers (never the globals directly). See
+  [[reconstruction-gotchas]] §6 duplicate-GLOBAL corollary.
 
 ## Key Relationships
 - Extends: [[pod-hardware]] (RIO input path) · Uses: [[gauges-hud]] dev-gauge modes ·

context/reconstruction-gotchas.md

@@ -121,6 +121,20 @@ mislanch.cpp's extern but not projweap.cpp's → first AUTOCANNON shot AV'd). **
 bridge-signature change, `grep -rn "extern .*<name>"` and update every declaration; then grep
 the fresh link output for the symbol name** — the pre-existing LNK2019 wall camouflages new
 entries if you only eyeball it.
+**Duplicate-GLOBAL corollary (glass per-display windows, 2026-07-20):** a global DEFINED in two
+libs (the 1995 headers declare free globals without `inline`/`extern`, so `application`,
+`ghWnd`, … exist in BOTH `munga_engine` and `bt410_l4`) links under `/FORCE:MULTIPLE` with
+per-object binding that is **non-deterministic across links** — a given `.obj` can resolve
+`application` to the copy the game ASSIGNS (correct) or to the other copy (stays NULL). A
+NEWLY-ADDED engine TU is the classic victim: it read `application == NULL` forever while
+`L4VB16.cpp` in the same lib read the assigned pointer, and a relink flipped which one was
+right. Symptom: a feature that reads an engine global silently no-ops (here: the gauge
+renderer came back NULL → blank glass surfaces), no crash, no link error. **Rule: from a fresh
+TU, never touch these duplicate globals directly — resolve through a tiny accessor DEFINED in
+the TU that OWNS the real pointer** (`game/btl4main.cpp` holds `btl4App`/`hWnd` as its own
+file-scope pointers; `BTResolveGaugeRenderer()`/`BTResolveMainWindow()` there are always
+correct). Do NOT "fix" it by adding the accessor to another engine TU — that binding is just as
+random. [T2]
 
 ## 7. Dtor-epilogue rule — do not reconstruct compiler glue