CydandClaude Opus 4.8
854ec0b216
Three real issues found while watching the live-render session against the actual running game and fixed: 1. STALE-FRAME SKIP (live_render.py): the renderer treated every single draw_scene as a frame to fully render+present. The game ticks at a measured ~28 draw_scene/s (matches the documented FAST 28Hz SOS clock), faster than our render, so a backlog built continuously -- we were perpetually rendering OLD content, which read as "frozen or 30s+ behind." Fix: SockSource.has_pending() detects an already-buffered next record; when backlogged, skip render+present (still consume/step normally) so we always show the freshest available state instead of crawling through history. pump() now drains aggressively so the backlog check is honest. 2. MID-MISSION CATCH-UP (live_render.py --catchup): reconnecting to an already-running pod produced a black screen. Root cause: draw_scene only means "render what's already loaded" -- it carries no geometry itself. The socket tee forwards only NEW traffic to a fresh client, so a from- scratch firmware boot has an empty scene graph. Fix: replay vpxlog's archival VPX_FIFODUMP (a second, independent sink of the same wire, written since pod boot) as the initial queue before going live -- exactly the same catch-up vpxlog's OWN native bridge already relies on for this same reason. 3. LIT-COLOR PLANE (gpu_raster.py): user-reported "textures are mostly grayscale" and "no fog effect." Found the actual mechanism in the real firmware source (sda4 DIVPXMAP.H + EOF.C): TREEclmpintoMEM (op 0x5a) writes dvpx_r24/g24/b24 -- a per-polygon lit color -- which EOF.C later copies into dvpx_eofr/g/b (the final screen color) via a straight 24-bit CPY in the simple (unfogged) case. Our renderer decoded this instruction but never used it, instead hardcoding flat polys to a placeholder (60,60,70) and sampling textures with no lighting modulation at all. Verified live on the wire: the value is a DIRECT 0-255-ish brightness (not a [0,1] float to rescale -- observed range ~49..395 with real per-polygon variation, only the brightest few clipping), consistent with a straight clamp-to-8-bit write. Now decoded (addr 118/126/134, empirically confirmed against DIVPXMAP.H's r24/g24/b24 spacing) and applied: flat polys get the real lit color instead of the placeholder; textured polys are tinted by it (texture * lit/255). Offline-tested (no crash, visibly plausible result: a lavender-tinted floor with real near/far gradient replacing the flat gray-blue placeholder) -- NOT yet cross-checked against a ground-truth screenshot, so treat the exact hue as provisional even though the underlying mechanism is verified real. Honest scope note: this changes gpu_raster's rendered colors on purpose, so it no longer bit-matches the OLDER frame_*.png CPU reference from before this fix (that reference predates lit-color decode). The geometry/perspective/ raster correctness those bit-identity tests proved is unaffected -- only the color post-process changed, layered on top. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Tesla Release 4.10 — Tesla:BattleTech & Tesla:Red Planet
Source code and game content for Tesla:BattleTech and Tesla:Red Planet, the two games that ran on the Tesla-generation simulator cockpits built by Virtual World Entertainment, Inc. (VWE). Source file headers are dated 1994–1996; this tree corresponds to release 4.10 of the Tesla software.
This repository is an archival snapshot. The tree is preserved byte-for-byte as
found (see .gitattributes — no line-ending conversion is applied).
See emulator/PLAN.md for the implementation plan to run these games on the surviving cockpits' Windows 10 computers via a VPX-board HLE device in DOSBox-X, with the cockpit RIO (COM1) and plasma display (COM2) passed through to the game's original drivers.
See HISTORY.md for findings from a recovered VWE developer hard drive that accompanies this tree (excluded from the repo), including Division renderer source, runnable game builds, unreleased prototypes (Star Trek, Hull Pressure, Renegade Legion, and the Starship Troopers pitch that became DisneyQuest's "Invasion!"), and an analysis of whether these games can be rebuilt from the sources in this repository (summary: the engine can, the games cannot — most game-logic sources are absent from this cut).
Target hardware
Each Tesla cockpit was driven by a server-class Pentium Pro machine running Novell DOS. Graphics were split across two adapters:
- The main (out-the-window) display was rendered by one of the first
pixel-pipeline 3D accelerator cards ever made, driven through Division Ltd.'s
dVS/DPL libraries (
libDPL— DPL, dsys, dvs, and the VPX headers; Division copyright 1995). - An S3 video adapter drove the other six cockpit displays (instrument
and gauge screens — see the
GAUGEcontent directories and thePCPIC.INC/L4GAU*gauge code).
Other hardware/OS interfaces:
- Audio: HMI SOS (Sound Operating System) —
sos/libraries, with variants for Borland (bc4) and Watcom (wc). - Networking: pods were networked over Ethernet using WATTCP (DOS TCP/IP, with BOOTP) via VWE's NetNub layer.
- Input: joystick/pedal/panel I/O in assembly (
JOYSTICK.ASM) and theL4CTRL*control modules.
Toolchain
- Borland C++ 5.0 (
BCC) with TASM32 for assembly — see the.MAKmakefiles (original build tree lived atD:\TESLA_RP\andD:\BC5\). - Precompiled-header discipline throughout (
.CSMheaders,#pragma hdrstop). VSSVER.SCC/MSSCCPRJ.SCCfiles are remnants of the original Visual SourceSafe source control.- File extensions:
.CPP/.HPPC++ source/headers,.TCP/.THPC++ template source/headers,.MAKBorland makefiles.
Repository layout
ARTTOOLS/ (empty placeholder — art tools were not included in this snapshot)
BORLAND/ (empty placeholder — compiler was not included in this snapshot)
CODE/ Game and engine source (~200k lines of C++/asm)
CONTENT/ Game data: models, animations, audio, maps, textures, gauges
HEADOFF/ Head/camera offset calibration configs for the cockpit displays
CODE/
Both games share the same architecture: a portable simulation engine (MUNGA, VWE's in-house engine) plus a hardware layer (MUNGA_L4, the "L4" Tesla pod platform layer), with game-specific code and a game-specific L4 layer on top.
CODE/BT/ Tesla:BattleTech
BT/ Game logic: mechs, weapons (PPC, Gauss, missiles),
damage tables, teams, missions, scenario rules
BT_L4/ BattleTech pod application layer (app modes, arena,
radar, playback, version)
MUNGA/ Engine bricks: math (matrices, angles, splines),
containers, file streams, audio manager, events
MUNGA_L4/ Pod hardware layer: video renderer manager, keyboard,
mouse, audio hardware, warehouse (resource loading)
LIBDPL/ Division Ltd. dVS/DPL graphics library (headers +
LIBDPL.LIB + VREND*.BTL renderer modules)
NETNUB/ WATTCP-based pod networking (headers + WATTCPLG.LIB)
SOS/ HMI Sound Operating System libraries + drivers
CODE/RP/ Tesla:Red Planet (same structure)
RP/ Game logic: VTV (hover racer) power/subsystems,
pickups (booster, blocker, crusher, thruster)
RP_L4/ Red Planet pod application layer
MUNGA/ Engine (fullest copy — 351 files incl. all .CPP)
MUNGA_L4/ Pod hardware layer (fullest copy, incl. JOYSTICK.ASM)
libDPL/, NetNub/, sos/ as above
*/opt/ Compiled Borland C++ 5.0 object files from the
original build (preserved as found)
Note: the BT copies of MUNGA/MUNGA_L4 are partial (69/68 files) while the RP copies are complete (351/231 files) — the BT tree appears to hold only the files that diverged from the shared engine.
CONTENT/
CONTENT/BT/ Tesla:BattleTech content
CONTENT/BT3025/ Parallel BattleTech content set (3025-era variant;
mostly identical to BT/ with a different mech roster)
CONTENT/RP/ Tesla:Red Planet content
Per-game content directories:
| Dir | Contents |
|---|---|
MODELS |
.MOD/.SUB/.DMG/.TBL — vehicle/mech models, subsystems, damage tables |
ANIMS |
.ANI — animations (BT only) |
AUDIO |
.MID MIDI music, .SCP audio scripts, .BNK/.BLD banks |
GAUGE |
.GIM — gauge images for the six S3-driven cockpit displays |
MAPS |
.MAP/.ZNE — arena/terrain maps and zones |
SOLIDS |
.SLD — collision solids |
VIDEO |
Division renderer data: GEO/ geometry, MAT/ materials, and TEX/ textures per environment (ARENA, DAY, NIGHT, DESERT, POLAR, CAVERN, …), .DZM skins, .BMF/.BGF binary geometry, BUILD/ sources |
SCENES |
Scene definitions (RP only) |
BTCAM |
Camera batch setups (BT only) |
DIVISION.SAV subdirectories inside VIDEO/ are backup saves written by
Division's tools. MTMCDAI.SYS (Mitsumi) and TAISATAP.SYS are DOS CD-ROM
device drivers used on the pod machines.
HEADOFF/
INI-style calibration files (.XST/.CAM/.BAK) defining viewing extents and
camera offsets ("head offset") for the cockpit's main display, including a
[LAB_ONLY] configuration.
Provenance
- Copyright (C) 1994–1996 Virtual World Entertainment, Inc. All rights reserved worldwide. Original headers mark the source as proprietary and confidential.
- Third-party components retain their own copyrights: Division Ltd. (dVS/DPL), Human Machine Interfaces (SOS), Erick Engelke / University of Waterloo (WATTCP).