From 1b204de6d38dd2c5dedd73566886455fa79fd519 Mon Sep 17 00:00:00 2001 From: Cyd Date: Mon, 27 Jul 2026 23:32:06 -0500 Subject: [PATCH] BT410: the 3-D path runs to mission load -- btl4vid's next brick is named Run against the emulated Division card, our build reaches the mission scene load and stops at the one method we stubbed: btl4vid.cpp(42): BTL4VideoRenderer::LoadMissionImplementation -- btl4vid.cpp not yet reconstructed That proves MakeVideoRenderer, the BTL4VideoRenderer ctor over the engine's DPLRenderer, the board boot (transputer + i860 firmware, ~858K wire transactions through the VPX HLE) and Renderer::LoadMission all work in our build. btl4vid is not a from-scratch climb; the engine half was always linked and what is missing is the mission-load hook and its renderables. Banked the reproduction rig (emulator/vidtest.conf + the host VPX env -- VPX_RESPOND alone is not enough, the iserver handshake dies without VPX_RENDER), the authentic contract from CODE/RP/MUNGA/RENDERER.CPP:263, and a note that the BT411 donor restructured this hook so the contract comes from the 1995 engine and only the renderables come from the donor. Also corrected today's earlier note: the transient 3-D frame seen during a gauge run was NOT the dPL path. MakeVideoRenderer returns NULL without DPLARG and no gauge conf sets it, so no video renderer exists in those runs. Co-Authored-By: Claude Fable 5 --- emulator/vidtest.conf | 27 ++++++++++ restoration/source410/RENDER-ROADMAP.NOTES.md | 53 +++++++++++++++++++ 2 files changed, 80 insertions(+) create mode 100644 emulator/vidtest.conf diff --git a/emulator/vidtest.conf b/emulator/vidtest.conf new file mode 100644 index 00000000..e9cb01b6 --- /dev/null +++ b/emulator/vidtest.conf @@ -0,0 +1,27 @@ +[sdl] +output=opengl +[dosbox] +memsize=32 +machine=svga_s3 +[cpu] +core=normal +cputype=pentium +cycles=20000 +[serial] +serial1=disabled +serial2=disabled +[autoexec] +mount c "C:\VWE\TeslaRel410\emulator\image" +c: +set L4CONTROLS=RIO,KEYBOARD +set L4TIMER= +set BLASTER=A220 I5 D1 H5 P330 T6 +set VIDEOFORMAT=svga +set BT_MECH_LOG=1 +set TEMP=c:\ +set DPLARG=/tranny~.\vrendmon.btl~/i860~.\vrnostex.mng~/device~0x150~/video~svga~/pipes~1~/qual~0x14~/system_tex~0~ +32rtm.exe -x +BTL4REC.EXE -egg test.egg > OUTREC.TXT +32rtm.exe -u +echo GAME-DONE-RC=%errorlevel% +exit diff --git a/restoration/source410/RENDER-ROADMAP.NOTES.md b/restoration/source410/RENDER-ROADMAP.NOTES.md index b8645dd7..fff94e62 100644 --- a/restoration/source410/RENDER-ROADMAP.NOTES.md +++ b/restoration/source410/RENDER-ROADMAP.NOTES.md @@ -81,3 +81,56 @@ Message-id / protocol quick refs: vr_create=1 (host-assigned handles), vr_flush=3 (node structs; VIEW proves 832x512), geometry 0x17/0x19/0x1a (texel word [pad,B,G,R]), artics 0x1f, draw 9, sync 0x2d, fire 0x23, reticle 0x26. DPLARG reference value in emulator/baseline.conf:21. + +================================================================================ +2026-07-27 -- THE 3-D PATH RUNS TO MISSION LOAD (measured, not estimated) +================================================================================ +Our reconstruction, run against the emulated Division card, gets ALL THE WAY to +the mission scene load before it stops -- at the one method we stubbed. + + c:/.../bt_l4/btl4vid.cpp(42): BTL4VideoRenderer::LoadMissionImplementation + -- btl4vid.cpp not yet reconstructed + +What that single line proves is working end to end in OUR build: + * BTL4Application::MakeVideoRenderer builds a BTL4VideoRenderer + * the BTL4VideoRenderer ctor chains the engine's DPLRenderer + * the board boots: transputer + i860 firmware upload, ~858K wire + transactions logged by the VPX device HLE + * Renderer::LoadMission runs (RENDERER.CPP:273) and calls the hook + +So btl4vid is NOT a from-scratch climb. The engine half was always linked; +what is missing is the game's mission-load hook and the renderables it builds. + +HOW TO REPRODUCE (this is the rig, and it is cheap): + emulator/vidtest.conf -- baseline.conf with the mount made absolute and + BTL4REC.EXE (our build, staged beside the shipped BTL4OPT.EXE which is NOT + touched) instead of the shipped exe. Host env before launching dosbox-x: + + VPX_RESPOND=1 VPX_RENDER=1 VPX_NOMAIN=1 VPXLOG= VPX_DUMPDIR= + + VPX_RESPOND alone is NOT enough -- with only that, the board boot dies at + "Protocol error : length 65535 too big / rcv_protocol fail during iserver + handling", which is the iserver handshake reading a floating bus. + VPX_NOMAIN=1 keeps it from opening windows; add VPX_EXPLODE=1 only when you + want the 7-display pentapus. The full documented pod launch is + render-bridge/launch_pod.ps1 (LAUNCH.md) when the GL bridge is wanted. + +THE CONTRACT for the next brick (authentic, CODE/RP/MUNGA/RENDERER.CPP:263): + Renderer::LoadMission verifies InactiveRendererStatus, sets + LoadingRendererStatus, stamps nextRenderTime, calls + GetRendererManager()->StartRenderer(this), THEN LoadMissionImplementation. + The base implementation Fails ("should never reach here") -- every concrete + renderer must override it. + +DONOR: BT411 game/reconstructed/btl4vid.cpp, 3188 lines / 27 methods, carrying +the renderable family (BTReticleRenderable, BTTranslocationRenderable, the +pending-wrecks map). NOTE it does not contain a LoadMissionImplementation by +that name -- the WinTesla port restructured the hook -- so take the CONTRACT +from the 1995 engine above and the CONTENT from the donor's renderables. + +CORRECTION to the note earlier today: a transient 3-D cockpit frame captured +during a gauge-rig run was NOT evidence of the dPL path emitting anything. +MakeVideoRenderer returns NULL unless DPLARG is set (BTL4APP.CPP:152), and no +gauge conf sets it -- so no video renderer exists in those runs at all. That +frame was almost certainly attract/loading art out of BTL4.RES. The evidence +above is the real thing, and it came from setting DPLARG deliberately.