BT410 5.3.64: THE COCKPIT EYE IS LIVE -- root+eye composition, and the emulator

deadlock it exposed

The camera gap root-caused and fixed through three layers:

LAYER 1 (ours): "chain the engine after the skeleton" was a non-fix.  The
engine's MakeEntityRenderables only accepts Object/Rubble resources, so
chaining it with a Skeleton printed "wrong video resource type" and built
NOTHING -- the fifodump proved it: zero vr_flush_dcs_artic records.  The real
fix mirrors the engine's Mover composition (L4VIDEO.CPP:4795-4860) inside our
mech case: a Dynamic RootRenderable (whose ctor seeds its DCS from
localToWorld and whose Execute re-flushes on change -- the ONLY source of
per-frame wire articulation), the skeleton hung UNDER its DCS via ReadSKLFile's
new parent_dcs parameter, and for the inside view a DPLEyeRenderable on that
root with the published EyepointRotation.  Also explains the mystery monolith
in the first frame: the skeleton was parked at the world origin with the
camera inside its shins.

LAYER 2 (1995 library, read from our own linked symbols): dpl_DrawSceneComplete
= velocirender_frameack(0), and frameack's unsolicited-reply path prints
"dpl error - unsolicited input during frame ack", adds the 1995 authors' own
puzzled "flush artic??" when the stray action is 0x1f, and calls exit(9).
Documented before it ever fires.

LAYER 3 (emulator, the actual deadlock): with per-frame articulation flowing
for the first time, the game stopped drawing at frame 232 -- one 0x1f burst
per frame forever, no receives, no error.  The VPX device feeds the frame ack
only after 6 CONSECUTIVE empty polls and reset that counter on EVERY
outputData write; per-frame articulation writes made the count unreachable, so
dpl_DrawSceneComplete never went true.  Fix: the reset is gated on
!frame_outstanding -- once a draw is outstanding the only receive the game
will do next is the frame ack.  The iserver-drain concern the reset guarded is
boot-time only, when no frame is outstanding.

Verified: two agreeing runs of ours on the fixed emulator (611 draws / 222
artic batches in run 2 -- the 232 wall is gone), camera travelling with the
mech (cam -329.7,0,60.5 -> -362.3,0,54.5 across 8s), anim_abs 0 -> 1 on the
bridge, view now INSIDE the cockpit cage.  Shipped binary re-run on the fixed
emulator: launches and runs, no regression.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

emulator/vpx-device/vpxlog.cpp

@@ -666,7 +666,22 @@ static void vpx_write(Bitu port, Bitu val, Bitu iolen) {
         note("board reset");
     } else if (off == 1) {
         saw_write = true;      /* outputData: a download/response byte */
-        empty_polls = 0;       /* a write means the game isn't blocking-reading */
+        /* A write means the game isn't blocking-reading -- UNLESS a draw is
+         * outstanding.  Once vr_draw_scene has been sent, the only receive
+         * the game performs next is the frame ack, but it keeps WRITING in
+         * the meantime: every frame flushes a vr_flush_dcs_artic batch (the
+         * per-frame vehicle articulation).  Resetting the poll counter on
+         * those writes starves the ack forever: one 0x1f burst per frame,
+         * one or two polls per frame, the counter never reaches
+         * POLL_THRESHOLD, dpl_DrawSceneComplete never returns true, and the
+         * game stops drawing while everything else runs on.  That deadlock
+         * appeared the FIRST time a game of ours produced per-frame
+         * articulation (2026-07-29); the shipped binary had simply never
+         * been run against this device in a state that both articulated
+         * and drew.  The iserver-drain guard this reset protects is a boot-
+         * time concern, when no frame is ever outstanding, so gating on
+         * frame_outstanding preserves it. */
+        if (!frame_outstanding) empty_polls = 0;
         fifo_flush_record();   /* outputData write = FIFO burst boundary */
         if (parse_frames) { parse_out_byte((unsigned char)val); fifo_arm_action(); }
     } else if (off == 4 || off == 5) {