BT411/context/wintesla-port.md

id, title, status, source_sections, related_topics, key_terms

id	title	status	source_sections	related_topics	key_terms
wintesla-port	The WinTesla Windows Port — the base everything builds on	established	PROGRESS_LOG.md §5b, §8	source-completeness rendering build-and-run multiplayer	WinTesla L4D3D MUNGA RP DPL

The WinTesla Windows Port

The Elsewhen RP411 archive is a working Windows port of the MUNGA engine (VS2005, WinTesla.sln). It means the hardest infrastructure is already solved — the bt411 build sits on top of it. Full detail: docs/PROGRESS_LOG.md §5b, §8.

What WinTesla already did (do NOT rebuild)

• Renderer bypass: DONE — MUNGA_L4/L4D3D.cpp + DXUtils replace libDPL / the IG board with Direct3D9. No libdpl.lib in the tree. (The early from-scratch D3D9 viewer was retired and removed.) [T1]
• Audio: BACKEND now REAL + soundbank loaded; only game-triggering remains [T2, updated 2026-07-15]. OpenAL replaces the HMI "SOS" engine and the renderer→device→buffer→source→play chain IS all implemented (L4AUDRND/L4AUDRES/L4AUDLVL; PatchLevelOfDetail::PlayNote really calls alSourcePlay). The "no sound, ever" root cause was DEEPER than a gate — both audio backend DLLs shipped in engine/lib/ were no-op STUBS: (a) libsndfile-1.dll exports 15 funcs BY ORDINAL ONLY (no names), sf_open() always returns NULL; (b) OpenAL32.dll (72KB) imported only KERNEL32 — no dsound/wasapi/winmm — so it returned fake handles (ctx=0x00000001, alGenSources→0) and never touched the hardware. So the chain ran clean and silent. FIXES (commit 5b46655): OpenAL32.dll → real OpenAL Soft 1.25.2 Win32 (drop-in: the exe imports the 25 AL funcs by NAME; alSourcePlay now reaches AL_PLAYING). libsndfile DROPPED — replaced by LoadWavPCM() in L4AUDRES (a tiny in-tree RIFF/WAVE fmt+data reader, no external dep). Gates fixed earlier: the AWE_FRONT/AWE_REAR env-var gate in MakeAudioRenderer was relaxed to default-on (BT_NO_AUDIO=1 disables). Soundbank recovered: 241 samples cracked from AUDIO1/2.RES (SF2 v1.0) by tools/sf2extract.py → content/AUDIO/*.wav + the allPresets[2][128] table (audiopresets.cpp, replacing the zero-init btstubs stub); all 241 load (alErr=0). In-game triggering now WORKS (commit 7b1e469): enabling audio unlocked L4AudioRenderer::CreateEntityAudioObjects, which binds AudioStateWatchers to entity/subsystem state attrs BY NAME (the attribute-pointer databinding, same as gauges) and calls AddAudioWatcher on the resolved StateIndicator. The reconstruction had pointed the Mech's state attrs at the scalar read-pad attrPad (fine for a gauge that READs a value, fatal for a state watcher that calls a METHOD → AV in SChainOf::Add on 0xCDCDCDCD). FIXED: the Mech's AnimationState/ ReplicantAnimationState (driven from SetBodyAnimation) and CollisionState (driven from ProcessCollision via collisionTemporaryState) are now real StateIndicator members — verified: walking fires SetupPatch+PlayNote/alSourcePlay (footstep/gait patches 78/80/116). So mech movement/animation/collision audio is live. Subsystem STATE audio DONE (commits 5ba541e/0e05a22/dcdd7dd): the audio watcher TYPE per attribute was recovered via a MakeObjectImplementation ClassID trace (class 28 = AudioStateTrigger/StateIndicator). KEY: the binary's 0x54-byte subsystem alarm (FUN_0041b9ec, reconstructed as GaugeAlarm54) IS a StateIndicator — its "three sub-indicators" @0x18/0x2c/0x40 are the audio/video/gauge watcher SChains, level@0x14 = currentState. The reconstruction had modeled that tail as an opaque _tail (never constructed → AddAudioWatcher AV'd on 0xCDCDCDCD). FIX: GaugeAlarm54 now has three REAL constructed sockets + AddAudioWatcher; SetLevel fires them on change (empty sockets = no-op, so other alarms/weapons unaffected; levelB/LevelCountB untouched; sizeof stays 0x54). Then registered each state attr → its subsystem's own alarm (own AttributePointers[] chained to the parent): Generator.GeneratorState→stateAlarm, Condenser.CondenserState→condenserAlarm, Reservoir.ReservoirState→reservoirAlarm, AmmoBin.AmmoState→ammoAlarm (+ chained AmmoBin's bare index so SimulationState resolves too). GeneratorOn→generatorOn. audiostate skips 85 → 0 — every StateIndicator audio attribute across the mech + all subsystems binds to a real indicator, and the alarms are already SetLevel'd by the sims, so generator/condenser/reservoir/ammo state sounds fire on transition. Still inert (read 0, silent, non-crashing — no modeled backing member in the size-locked layouts, a polish follow-up): ReportLeak (Logical), ConfigureActivePress (Integer), Torso.MotionState (Enum), Torso.SpeedOfTorsoHorizontal + ControlsMapper.TargetRangeExponent (Scalar). The bring-up guards [T3, self-clearing] stay: a NULL subsystem attr → inert pad (was a fatal Fail); an AudioStateWatcher on an unconstructed indicator (chain@+0x18 null/0xCDCDCDCD) → skip. Both pass automatically once a subsystem is built. Diagnostics: BT_AUDIO_LOG (chain + skips/redirects), BT_ATTRBIND_LOG (every attr bind), BT_AUDIO_TEST (proof-of-life buffer0). NOTE: AUDIO1/2.RES were SF2 v1.0 (16-byte shdr; sample rate assumed 22050 Hz — may need tuning if pitch is off).
• L4 HAL on Windows + the VS build system: DONE. [T1]
• Red Planet game logic: COMPLETE & buildable — VTV/VTVMPPR/WEAPSYS/.... RP is at/near playable. [T1]
• Multiplayer: the DOS NETNUB driver is already replaced by a ~3.5k-line WinSock2 TCP reimplementation (MUNGA_L4/L4NET.CPP) + the master/replicant distributed-sim core. See multiplayer. [T1]

What BT still needs (the only remaining work below the game layer is NONE)

Everything below the game layer — engine, renderer, audio, HAL, build — exists and is shared. The ONLY thing BT needs is its game-logic source, which is gone (see source-completeness) → it must be reconstructed, with the three anchors (BT headers + the WinTesla engine to compile against + RP's parallel code + the binary oracle). [T2]

Build implications

• WinTesla.sln is VS2005 and hard-depends on the legacy DirectX SDK (June 2010) (d3dx9, dinput, dxerr — all removed from the modern Windows SDK). The DXSDK is installed at C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\. [T2]
• The shared engine builds GREEN to munga_engine.lib via CMake/MSVC Win32 (see build-and-run). Recipe gotchas (include-path shadowing, the CAMMGR/time.h fixes, the ATL shim) are in docs/PROGRESS_LOG.md §8. [T2]

Roadmap position

Old plan ("build a libDPL shim + port the engine") is superseded — WinTesla did it. New plan: reuse the WinTesla engine (shared) + reconstruct the BT game library (BT410_L4 + game logic). The from-scratch libDPL shim is no longer needed. Phases 4-8 (BT game layer + pod bring-up) still apply. [T2]

Key Relationships

• Solves: the infrastructure that source-completeness would otherwise require.
• Feeds: build-and-run, rendering, multiplayer.