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

BT410 5.3.48: watcher ladder complete; the engine names the next brick

Browse Source 
With every authored watcher resolving, the pod run reaches the mission, draws
the FULL COCKPIT with the board booted and audio running, and exits GAME-RC=0
with no Fail.  It builds no 3-D scene, and the engine says why:

  Entity 1:1 class3035 couldn't figure out how to MakeEntityRenderables
  L4VIDEO.cpp couldn't load object sky.bgf  (then the whole arena)
  NULL instance

VideoRenderer::MakeEntityRenderables (VIDREND.CPP:231) is the BOTTOM of a
virtual chain -- its comment says so outright -- and BTL4VideoRenderer does
not override it, so every entity falls through, no scene graph is built, and
the geometry that would hang off it never loads.

CORRECTS an earlier note in the roadmap: I recorded the first full-rig run as
proving '.BGF loading was never a reconstruction problem, only a missing
bridge', because the complaint count was zero.  It was zero because the run
Failed at a watcher long before reaching geometry.  Now that it gets there,
the loads are attempted and fail -- for want of renderables, not the bridge.

Next brick is the real btl4vid body, shape pinned by the surviving sibling
header RPL4VID.HPP: override MakeEntityRenderables, plus ReadSKLFile /
RecurseSKLFile to walk the .SKL skeleton pages into a dpl_DCS hierarchy and
load the .BGF geometry per node.  Renderable content from the BT411 donor.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-28 08:22:44 -05:00
co-authored by Claude Fable 5
parent 4168f1ad4d
commit 32023a918f
3 changed files with 111 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/render-bridge/gauge_arena_rec.conf
+2 -1
View File
@@ -53,7 +53,8 @@ set HEAPSIZE=15000000
set L4GAUGE=640x480x16
call setenv.bat r f s p
32rtm.exe -x
BTL4REC.EXE -egg testarn.egg > OUTREC.TXT
BTL4REC.EXE -egg testarn.egg > OUTREC.TXT
echo GAME-RC=%errorlevel% >> RC.TXT
32rtm.exe -u
echo ALPHA1-RUN-DONE
emulator/render-bridge/gauge_arena_rec_console.conf
+60
View File
@@ -0,0 +1,60 @@
[sdl]
output=opengl
# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
priority=higher,higher
[dosbox]
memsize=32
machine=svga_s3
[cpu]
core=dynamic
cputype=pentium
cycles=max
[sblaster]
sbtype=sb16
sbbase=220
irq=5
dma=1
hdma=5
[mixer]
# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
# emulation-thread stalls (RIO retry recovery) don't audibly chop
rate=44100
blocksize=1024
prebuffer=60
[serial]
# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
serial1=namedpipe pipe:vrio rxpollus:100 rxburst:16
serial2=namedpipe pipe:vplasma
[autoexec]
mount c "C:\VWE\TeslaRel410\ALPHA_1"
c:
cd \REL410\BT
set VIDEOFORMAT=svga
rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
rem driver relies on; skipping it left the cards uninitialized (silent).
rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
set BLASTER=A220 I5 D1 H5 P330 T6
c:\sb16\diagnose /s
set BLASTER=A240 I7 D3 H6 P300 T6
c:\sb16\diagnose /s
set BLASTER=A220 I5 D1 H5 P330 T6
set TEMP=c:\
rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
rem attached; stdout redirected so mission-load progress survives kills.
set HEAPSIZE=15000000
set L4GAUGE=640x480x16
call setenv.bat r f s p
32rtm.exe -x
BTL4REC.EXE -egg testarn.egg
32rtm.exe -u
echo ALPHA1-RUN-DONE
pause
restoration/source410/RENDER-ROADMAP.NOTES.md
+49
View File
@@ -385,3 +385,52 @@ THE REUSABLE TECHNIQUE: when the pod dies with an extender fault, take the
address out of the dump, subtract 0x410000, and look it up in
btl4opt.map. It names the exact engine function -- which, for this family of
work, names the watcher class and therefore the required member type.
--------------------------------------------------------------------------------
THE WATCHER LADDER IS DONE -- and the next brick is named by the engine itself
--------------------------------------------------------------------------------
Every authored AttributeWatcher now resolves. The pod run reaches the mission,
DRAWS THE FULL COCKPIT (sensor cluster, myomers, cooling, the weapon panels,
kills/deaths) with the board booted and audio running, and exits GAME-RC=0
without a Fail. What it does NOT do is build a 3-D scene, and the engine says
why in one line:
Entity 1:1 class3035 couldn't figure out how to MakeEntityRenderables
L4VIDEO.cpp couldn't load object sky.bgf (then the whole arena:
aw02/aw03/aw04/afloor/bcor1/bdet1/bdet2/bpip1 ...)
NULL instance
VideoRenderer::MakeEntityRenderables (CODE/RP/MUNGA/VIDREND.CPP:231) is the
BOTTOM of a virtual chain -- its own comment says "when a higher level of this
virtual can't figure out how to make something it calls down to the level
below it. If we reach here then nobody could figure out what to do." Our
BTL4VideoRenderer does not override it, so every entity falls through to the
complaint, no scene graph is built, and the arena geometry that would hang off
it never loads. class3035 = 0xBDB.
CORRECTION to the earlier note in this file: the first full-rig run was
recorded as "geometry complaint count went to ZERO -- .BGF loading was never a
reconstruction problem, only a missing bridge". That reading was wrong. The
count was zero because the run Failed at an attribute watcher long BEFORE
reaching geometry. Now that the watchers all resolve, the loads are attempted
and they fail -- because nothing built the renderables to hang them on, not
because of the bridge.
SO THE NEXT BRICK IS THE REAL btl4vid BODY, and its shape is pinned by the
surviving sibling header CODE/RP/RP_L4/RPL4VID.HPP:
void MakeEntityRenderables(Entity*, ResourceDescription *model_resource,
ViewFrom type); <- override this
dpl_DCS* ReadSKLFile(Entity*, ResourceDescription*, ViewFrom,
char skeleton_type);
void RecurseSKLFile(Entity*, dpl_DCS *parentDCS, NotationFile *skeleton,
const char *page_name, int recursion_depth, ViewFrom,
int *joint_counter, dpl_LOAD_MODE cache_mode);
char SetupMaterialSubstitutionList(Entity*, ViewFrom);
void TearDownMaterialSubstitutionList();
i.e. walk the mission's entities, read each one's .SKL skeleton notation pages
(VIDEO/*.SKL are present in the mount), recurse them into a dpl_DCS hierarchy,
and load the .BGF geometry per node. Content for the BT-specific renderables
comes from the BT411 donor (game/reconstructed/btl4vid.cpp, 3188 lines:
BTReticleRenderable, BTTranslocationRenderable, the pending-wrecks map).