CydandClaude Opus 4.8 ef7db9f2e4 Fix live-render lag: bulk memory read + masked texture compositing (~2.1x)
User-visible bug: connected the reconstructed renderer to the REAL running pod
for the first time (M4d demo) and the render fell increasingly behind the live
game, plus looked near-grayscale. Root-caused with direct profiling instead of
guessing:

1. VPX_RENDER=1 was set in launch_live.ps1 (copied from launch_pod.ps1's
   defaults without thinking it through) -- it starts vpxlog.cpp's OWN native
   GL render thread (rt_main), which contends with our renderer for the same
   CPU/GL resources. Live-caught: with it set, wire delivery stalled at wire
   command 8 for 90+s; removing it, the same mission reached command 21,488
   in the same window. This was the dominant cause of the visible lag.

2. gpu_raster.build_prims() scanned the whole per-draw program window
   (0x08158000-0x08170000, ~24k words) via a Python-level r32() call per word
   every frame. Added emu860c.dump_range(lo,hi)->bytes (one bulk C read) and
   rewrote build_prims to index a numpy array instead -- verified byte-identical
   dump_range output first, then reconfirmed the whole render is STILL
   bit-identical to the CPU reference (frames 0/5/11, differ>24 = 0.000%).

3. Profiling after (1) showed the per-texture compositing loop was the real
   remaining cost: 62ms/frame doing full-832x512-frame fancy-indexed texture
   sampling for EACH of 13 textures, regardless of how few pixels use each one.
   Added dpl_sampler.composite_masked (sample+composite only the pixels a
   texture actually covers; verified equivalent to composite() on a partial
   mask in dpl_sampler's own conformance test) and hoisted the invariant
    out of the loop.

Combined: render time 95.8ms -> 54.9ms/frame (~1.75x from this change alone,
~2.1x vs the original ~117ms/frame baseline), still bit-identical to the CPU
reference throughout.

launch_live.ps1: removed VPX_RENDER, renamed the automatic-variable shadow
 ->  (flagged by PSScriptAnalyzer), added -Pin <fifodump> to
pre-load the full texture set (bit-identical to offline) instead of the
incremental default, for a demo that wants correct color immediately rather
than waiting on the live mission's own upload order.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 10:07:55 -05:00

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 19941996; 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 GAUGE content directories and the PCPIC.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 the L4CTRL* control modules.

Toolchain

  • Borland C++ 5.0 (BCC) with TASM32 for assembly — see the .MAK makefiles (original build tree lived at D:\TESLA_RP\ and D:\BC5\).
  • Precompiled-header discipline throughout (.CSM headers, #pragma hdrstop).
  • VSSVER.SCC / MSSCCPRJ.SCC files are remnants of the original Visual SourceSafe source control.
  • File extensions: .CPP/.HPP C++ source/headers, .TCP/.THP C++ template source/headers, .MAK Borland 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) 19941996 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).
S
Description
No description provided
Readme
427 MiB
Languages
1C Enterprise 21.7%
C++ 20.5%
C 20.5%
Assembly 15.2%
Scheme 6%
Other 15.6%