CydandClaude Fable 5
af010c18c2
MakeEntityRenderables no longer stops after the skeleton. It builds ours AND
chains DPLRenderer, which is what creates the RootRenderable and the
DPLEyeRenderable the camera follows. Verified over three runs:
[mer] 208 class=3001 view=1 res=1
[vid] type=1 file='mad.skl'
[skl] video\mad.skl -> 26 nodes, 19 objects
[chain] into DPLRenderer, skeleton=yes, stack at 0x12dde7
No fault, mission launches, sim runs. Worth noting separately: the engine's
eyepoint construction -- prime suspect for the page fault through most of a
session -- runs perfectly here, with the stack at 0x12dde7, right beside the
main loop's frame. Both are consistent with the corrected finding that the
fault is a live-RIO artifact at a fixed DPMI host address.
The camera still does not move: two frames six seconds apart differ by zero
pixels while [sim] shows the mech travelling from (487,20,288) to (493,20,301),
and the bridge reads cam (0.0, 10.0, 0.0) -- world origin plus eye height. So
the eye renderable was necessary but not sufficient.
Eliminated by reading our own code rather than guessing: the viewpoint entity
IS the mech (BTL4APP.CPP:354), the video renderer IS linked to it
(APP.CPP:1337), and SetupCull would Fail() loudly if the mech lacked
"siteeyepoint" or EyepointRotation -- neither Fail appears. That leaves the
path from SetupCull's worldToEyeMatrix to what the bridge reads off the wire,
which is bridge territory rather than reconstruction territory.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
95 lines
3.5 KiB
Plaintext
95 lines
3.5 KiB
Plaintext
# pod_render_chain.conf -- pod_render_norio plus BT_MECH_CHAIN=1.
|
|
#
|
|
# The mech case sets handled=True once ReadSKLFile finds a skeleton and
|
|
# then SKIPS DPLRenderer::MakeEntityRenderables -- which is the call that
|
|
# builds the RootRenderable and the DPLEyeRenderable the camera follows.
|
|
# So the board gets a skeleton with no root and no eye, and the view stays
|
|
# frozen at the origin while the mech walks away. BT_MECH_CHAIN clears
|
|
# handled so the engine runs TOO. RIO off, because a live vRIO stream
|
|
# faults this build -- one variable at a time.
|
|
#
|
|
# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
|
|
#
|
|
# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
|
|
# the RIO pipe, and controls post their events at HighEventPriority
|
|
# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
|
|
# flood a priority the background pump always serves first, starving the
|
|
# priority-0 renderer events the load gate waits on. This conf tests that
|
|
# by removing the port entirely. Everything else is identical to the rec
|
|
# conf, so a launch here and a hang there isolates the RIO.
|
|
#
|
|
[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=disabled
|
|
serial2=namedpipe pipe:vplasma
|
|
# live UNBUFFERED game output: DOS char devices are not buffered, so
|
|
# redirecting stdout to COM3 lands every line immediately. A normal
|
|
# '> file' redirect stays 0 bytes until the process exits, which hides
|
|
# all progress on a run that does NOT crash.
|
|
serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
|
|
[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 BT_MECH_LOG=1
|
|
set BT_MER_LOG=1
|
|
set BT_MECH_CHAIN=1
|
|
set BT_LAUNCH_LOG=1
|
|
set BT_STACK_LOG=1
|
|
set BT_FORCE_THROTTLE=0.6
|
|
set BT_FORCE_TURN=0.25
|
|
set HEAPSIZE=15000000
|
|
set L4GAUGE=640x480x16
|
|
call setenv.bat r s n p
|
|
32rtm.exe -x
|
|
BTL4REC.EXE -egg testarn.egg > COM3
|
|
|
|
echo GAME-RC=%errorlevel% >> RC.TXT
|
|
32rtm.exe -u
|
|
echo ALPHA1-RUN-DONE
|
|
pause
|
|
|