CydandClaude Fable 5
4cf09917ce
The previous commit's attribution was wrong and is corrected in the roadmap. WRONG: 'the crash is the skeleton walk's' rested on 0 crashes in 2 runs with the walk disabled -- a 25% coin flip presented as evidence. The oldest preserved dump has no [skl] line and ends on the old 'couldn't figure out how to MakeEntityRenderables' fallback, so it predates the walk and faults identically. WRONG: 'it lands at different points each time'. Every dump carries the same numbers to the byte (cr2 7000FA64, EIP 66D9). What varies is how far the log gets, not where the fault is. Resolving the address through btl4opt.map names it exactly: EulerAngles::operator=(const LinearMatrix&)+0x19, a read through the matrix reference. A binary scan finds all three call sites of that operator pass a stack local, so the 1.79GB pointer still has no static explanation -- that is now its own open item rather than a guess. Two theories killed cleanly by the new BT_STACK_LOG probe and a binary scan: ESP drift (drift=0 over 2002 frames; exactly one callee-cleans function exists in the whole binary) and an undersized stack (our PE and the shipped one have identical 1MB/8K geometry). What the probe found matters more: the application is parked in state=2, which is LoadingMission, not WaitingForLaunch. Priority 0 is where the interest manager queues renderer events during load, the gate needs that priority empty, and it never empties -- so the mission never launches and the renderer holds a blank screen by design. The fault arrives ~30s into that wait. Runs that DO launch never print a single [launch] line. So 'crashes half the time' and 'hangs during load' are one event seen twice. A 15x disagreement between two clocks looked like a reconstruction slip -- BTL4.CPP passes GetTicksPerSecond() where ApplicationManager wants a frame rate. Checked against the shipped binary before touching it: same instruction sequence, same kind of static float pushed. Authentic. Documented so nobody 'fixes' it. Also swept every subsystem DefaultData against its real C++ base. Fifteen chain past their immediate parent, but fourteen skip only classes that add no handlers and no attributes, and no class's attribute-ID base disagrees with its index chain -- so there are no gap slots there. The one real defect: Generator is a HeatSink but chained to Subsystem::MessageHandlers, so it ignored every ToggleCooling message. Fixed (compiles next build). Tooling: podrun.sh stages the build over BTL4REC.EXE, exports the host-side VPX board env -- without which the run dies at the iserver handshake rather than merely rendering nothing -- and archives every run's log, marking it -CRASH when it faulted. Before this the only preserved dump was an accident, on a rig where each run costs four minutes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Scene Restorations
Modern re-renderings of the Division dVS scenes recovered from the Glaze developer drive (see HISTORY.md) and this repo's CONTENT tree. The originals ran on Division Ltd.'s pixel-pipeline hardware in 1994–1997; these tools parse the original data files and re-render them in WebGL, in the browser.
Viewers (open in any browser, fully self-contained)
vwe-archive.html— the Scene Archive: 26 curated scenes across all projects — Star Trek (Enterprise-D, Klingon flyby), Hull Pressure (sea demos, fish schools, sunken temple), BattleTech (polar map with mech lineup, Ravine and desert maps, stadium), Red Planet (Blade arena, the Mars canal milestone demo), and the Canyon/Maya-temple Division demos. Fly camera: drag to look, WASD to fly, R resets.trek-scn.html— the original standalone Star Trek restoration (TREK.SCN and KLNGVID.SCN).
Toolkit
divformats.py— parsers for every Division format found on the drive: textVGF/VMF(DIV-VIZ2 geometry/materials, both the 1995VERSION 2:07and 199602:05dialects, with header SCALE support), binaryBGF/BMF(DIV-BIZ2) — the binary block-stream layout was recovered from Division's own reader source (DPL3/BIZREAD.C, 1994), including all 14 vertex layouts, pmesh/tristrip/polygon connectivity, LOD blocks (newer writers nest patches inside LODs; the largest LOD is taken), and embedded materials/textures/ramps — plusTGAand rawSVTtextures,SPLsplines, andSCNscene scripts.audit.py— scans every.SCNon the drive and reports what fraction of its geometry survives, and in which format.extract_all.py— extracts every scene with ≥60 % of its geometry recoverable (108 of 241 on the drive; the rest reference lost models) intoallscenes.json, resolving models/materials/textures across the drive and this repo's CONTENT dirs.gallery_build.py— curates scenes fromallscenes.jsoninto the self-containedvwe-archive.html(viagallery_template.html).convert.py/viewer_template.html— the original single-scene Star Trek pipeline.
Rebuild
python extract_all.py # requires the sda4/ drive dump beside this repo
python gallery_build.py
Fidelity notes
Faithful: vertices, triangles, material colors and shading ramps, textures,
fog and light parameters, spline motion, camera start positions. Approximated:
Division's rasterizer behavior, point sizes, timing (originals ran at 30 Hz).
Not simulated: event-driven SPECIALFX particles. A few dev scenes had camera
start positions inside geometry; those get overridden or auto-framed cameras
(see START_OVERRIDE in gallery_build.py). Scenes missing one or more
models from the drive say so in their header.