CydandClaude Fable 5
f0f0e3d70e
The mech rendered with a live root and frozen limbs. Cause, and it is not in
the renderer:
L4VIDRND.CPP:1028 sets SINGLE_AXIS_HINGE True, so HingeRenderable pushes a
joint with dpl_SetDCSXAxis / YAxis / ZAxis -- three separate libDPL entry
points, each handed only (sine, cosine). The AXIS is carried by WHICH
FUNCTION WAS CALLED, and libDPL never puts it on the wire.
Confirmed against a live capture rather than argued: every articulation
record in joints_check.fifodump is 12 bytes, [handle][sin][cos], 26133 of
them, no axis field anywhere. And the renderer cannot recover it from
context either -- that capture contains ZERO action-0x22 name records, so a
DCS handle cannot be matched back to a .SKL node. vrboard was parsing those
records correctly and dropping them on purpose, with a comment saying so.
THE FIX is the archive's own alternative. The #else half of that same #if
(L4VIDRND.CPP:1153) builds a Quaternion from the Hinge and assigns it over
the DCS matrix -- the axis ends up IN the matrix, and it flushes as a
12-float pose the renderer already applies. That is precisely what
BallJointRenderable::Execute does unconditionally, with no #if at all, which
is why ball joints were never affected. So this is the branch the original
authors wrote and did not take, applied to hinges so they behave like the
ball joints beside them.
A DCS REMEMBERS HOW IT WAS LAST SET -- the part that cost a build.
The first attempt subclassed HingeRenderable and overrode only Execute. It
compiled, ran, and did not work: the wire still carried 12-byte records. What
it DID change was their contents -- the pair went from (sin, cos) to
(0.9990, 0.0000), which is m00 and m01 of the matrix being written. That is
the whole diagnosis in one number. The base ctor calls dpl_SetDCS?Axis before
the subclass gets control, which puts the DCS in single-axis mode, and the
flush then serialises two floats out of it no matter what goes in through
dpl_GetDCSMatrix.
So the axis setter must never touch this DCS. BTL4HingeRenderable therefore
derives from ChildOffsetRenderable, whose ctor builds the offset DCS and calls
no axis setter -- making it the exact hinge analogue of BallJointRenderable:
same base, holds its own attribute pointer plus a previous-value copy, writes
a full matrix in Execute. CODE/ untouched; Component::Execute is virtual
(CMPNNT.HPP:40) so the override dispatches normally, and shadowing 1900 lines
of L4VIDRND.CPP to flip one #define was not needed.
VERIFIED on the rig, torso-sweep conf, clean run:
before 26133 records, ALL 2-float, 1 handle, renderer applied NOTHING
after 7626 records, ALL 12-float, ZERO 2-float messages remaining,
22 handles emitted, renderer applied all 22 (anim_abs)
and the swept joint moves: handle 0x684, m00 across 1532 distinct values
from 0.1582 to 1.0000 -- cos of a 0..80 degree sweep, which is exactly what
BT_FORCE_TORSO drives.
LEG GAIT: NOT FIXED, and the earlier note claiming this would fix it was
wrong. The transport was necessary but not sufficient. On a walking run
(new pod_render_joints.conf = the arena mission with BT_JOINTS) all 22 joints
flush as matrices and the renderer applies them, but only handle 0x672 -- the
vehicle ROOT -- animates. The limbs emit their initial pose and never change.
Because nothing drives them. Joint::SetHinge / SetRotation exist, and the
ONLY caller anywhere in the reconstruction is TorsoSimulation
(BT/TORSO.CPP:382, horizontalJointNode->SetRotation). That is why the
torso is the one thing that moves. MAD.SKL declares JointCount=25 --
jointhip, jointlthigh, jointrthigh, jointtorso, jointshakey, jointeye and
the rest -- and the gait that should walk them is simply not reconstructed
yet. Separate piece of work, now unblocked rather than done.
HARNESS CAVEAT: pose_probe frames on "the last-articulated root" in
anim_abs. With 21 joint DCSs now landing there, that heuristic picks a joint
instead of the vehicle root and frames empty arena. The change invalidated
the assumption; the render is not evidence either way until it takes the root
handle explicitly. The counts above are the evidence.
FAULTS SEEN: two crashes during this work, both cr2=7000FA64 at host 66D9 --
the known parked load-window fault, address unmoved across a relink (which is
the standing test for "not ours"). They died at DIFFERENT points ([mer] 217
and [mer] 116), where a defect in new construction code would die
consistently. Third and fourth runs clean.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
87 lines
3.0 KiB
Plaintext
87 lines
3.0 KiB
Plaintext
# 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_JOINTS=1
|
|
set BT_MECH_LOG=1
|
|
set BT_MAP_LOG=1
|
|
set BT_MER_LOG=1
|
|
set BT_VID_LOG=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
|
|
|