CydandClaude Fable 5
d143f833ab
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>
100 lines
3.4 KiB
C++
100 lines
3.4 KiB
C++
//===========================================================================//
|
|
// File: btl4vid.hpp //
|
|
// Project: BattleTech //
|
|
// Contents: Implementation details for the BT video renderer //
|
|
//---------------------------------------------------------------------------//
|
|
// Date Who Modification //
|
|
// -------- --- ---------------------------------------------------------- //
|
|
// //
|
|
//---------------------------------------------------------------------------//
|
|
// Copyright (C) 1995, Virtual World Entertainment, Inc. //
|
|
// All Rights reserved worldwide //
|
|
// This unpublished sourcecode is PROPRIETARY and CONFIDENTIAL //
|
|
//===========================================================================//
|
|
|
|
#if !defined(BTL4VID_HPP)
|
|
# define BTL4VID_HPP
|
|
|
|
# if !defined(L4VIDEO_HPP)
|
|
# include <l4video.hpp>
|
|
# endif
|
|
|
|
# include <dpl.h>
|
|
# include <dplutils.h>
|
|
|
|
//###########################################################################
|
|
//####################### BTL4VideoRenderer #############################
|
|
//###########################################################################
|
|
|
|
class BTL4VideoRenderer:
|
|
public DPLRenderer
|
|
{
|
|
public:
|
|
BTL4VideoRenderer(
|
|
RendererRate calibration_rate,
|
|
RendererComplexity calibration_complexity,
|
|
RendererPriority calibration_priority,
|
|
InterestType interest_type,
|
|
InterestDepth depth_calibration
|
|
);
|
|
~BTL4VideoRenderer();
|
|
|
|
protected:
|
|
void
|
|
LoadMissionImplementation(Mission *mission);
|
|
|
|
//
|
|
// (A diagnostic ExecuteImplementation wrapper briefly lived here to
|
|
// count dynamic renderables per frame; it cannot exist, because
|
|
// DPLRenderer::ExecuteImplementation is PRIVATE -- virtual dispatch
|
|
// reaches it, but a subclass cannot chain it by name. The question
|
|
// it was built to answer got answered by the wire instead: zero
|
|
// vr_flush_dcs_artic records because NO dynamic renderable existed
|
|
// -- the engine rejects Skeleton resources, so chaining the base for
|
|
// the mech built nothing. See MakeEntityRenderables.)
|
|
//
|
|
|
|
//
|
|
// The bottom of this virtual chain is
|
|
// VideoRenderer::MakeEntityRenderables (VIDREND.CPP:231), whose own
|
|
// comment says it is only reached when nobody above could figure out
|
|
// what to build -- and it just complains. The engine's DPLRenderer
|
|
// layer knows the ENGINE classes; the game's own classes are ours.
|
|
//
|
|
void
|
|
MakeEntityRenderables(
|
|
Entity *entity,
|
|
ResourceDescription *model_resource,
|
|
ViewFrom view_type);
|
|
|
|
//
|
|
// The mech's model resource is a SKELETON, not an object, and the
|
|
// engine rejects it ("wrong video resource type") because building
|
|
// one is the GAME renderer's job. Shape taken from the surviving
|
|
// sibling header CODE/RP/RP_L4/RPL4VID.HPP.
|
|
//
|
|
dpl_DCS *
|
|
ReadSKLFile(
|
|
Entity *entity,
|
|
dpl_DCS *parent_dcs,
|
|
const char *skeleton_filename,
|
|
ViewFrom view_type);
|
|
|
|
dpl_DCS *
|
|
RecurseSKLFile(
|
|
Entity *entity,
|
|
dpl_DCS *parent_dcs,
|
|
NotationFile *skeleton,
|
|
const char *page_name,
|
|
int recursion_depth,
|
|
ViewFrom view_type,
|
|
dpl_ZONE *zone,
|
|
int *node_count,
|
|
int *object_count);
|
|
|
|
protected:
|
|
int reserved[16];
|
|
};
|
|
|
|
#endif
|