BTL4VideoRenderer now overrides MakeEntityRenderables. Class 3035 resolves to BTPlayerClassID (the BT enum block starts at 3000 in VDATA.HPP), and a player carries no graphics -- exactly what the engine already does for its own PlayerClassID with an empty case. Everything else chains to DPLRenderer, so the override can only add answers. On the pod: the 'couldn't figure out how to MakeEntityRenderables' complaint is gone and the run no longer exits, it keeps running. It still renders nothing -- the wire fifodump grows at ~24 bytes/sec, keep-alive rather than a frame stream -- which is expected, since only the player has been answered and the mech and arena still have no renderables. Banked a practical problem worth fixing before the next session: a pod run that does NOT crash produces no readable log, because the conf redirects the game's stdout and DOS buffers it. Every readable log this session came from a run that crashed and had its buffer flushed by the fault handler. The RC.TXT marker (a separate command) survives that, and the com3/serial3=file trick from the emulator notes would give live unbuffered output -- worth wiring in, otherwise progress is invisible precisely when things are going well. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
61 lines
2.2 KiB
C++
61 lines
2.2 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
|
|
|
|
//###########################################################################
|
|
//####################### 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);
|
|
|
|
//
|
|
// 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);
|
|
|
|
protected:
|
|
int reserved[16];
|
|
};
|
|
|
|
#endif
|