Files

T

CydandClaude Fable 5 2c29bf928d Add FLYK render harness from VWETEST diagnostic suite

The production image's VWETEST diagnostic suite provides a clean,
game-independent render harness. FLYK (VGLTEST, 32rtm build, newer
token-based sync) + clear.scn drives the ENTIRE VPX protocol through
the emulated board with zero errors: boot, iserver handshake, i860
download, token sync, scene build, draw_scene, frame-ack, clean exit
('Exiting rendering'). This validates the VPX emulation for an
arbitrary DPL renderer, not just the game.

Notes: the CYCLE flyk is a DOS/4GW build using the OLDER DPL3-style
velocirender_sync (action-check) and needs separate handling; the
VPX/DBE0151 iserver board test + reference TGAs are a future
golden-image validation avenue.

Adds RENDER-HARNESS.md and harness configs (flyk/cycle/alpha1).
Next (Phase 3): flyk DIVRGB.SCN color bars -> decode FIFO geometry
(same DIV-BIZ2 formats as restoration/divformats.py) -> OpenGL.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-07-03 09:27:52 -05:00

3.5 KiB

Raw Blame History

Render harness — FLYK + the VWETEST diagnostic suite

The production cockpit image ALPHA_1/VWETEST/ contains VWE's hardware diagnostic suite, which turns out to be an excellent, minimal harness for developing and validating the VPX board emulation — far simpler than driving the full game.

What's in VWETEST

VGLTEST/FLYK.EXE — Division's standalone scene flyer (flyk <scene.scn> <camera.spl>). Boots the VPX renderer and draws a scene along a camera spline. No game logic, no RIO, no NetNub. Uses the Borland 32RTM extender and the newer token-based velocirender_sync (the one this device already handles). This is the primary harness.
VGLTEST/*.SCN — calibration scenes of increasing complexity: CLEAR.SCN (black, no geometry), DIVRGB.SCN / DIVBRT.SCN / DIVPA.SCN (color-bar / brightness / RGB calibration geometry from DIVISION/*.BGF), DIVCAL.SCN.
CYCLE/ — a full render-cycle test: flyk yip.scn camera.spl rendering real Red Planet geometry (REDPLANT.BGF) with dynamic objects and events. NOTE: this FLYK is a DOS/4GW build using the older DPL3-style velocirender_sync (action-check, not token) — it currently hits unexpected action 1 in velocirender_sync against this device. Two sync protocol variants exist; the device implements the newer one.
VPX/DBE0151, VPX/DBI0152 — low-level board diagnostics that use the actual INMOS ISERVER.EXE to boot a TEST.BTL onto the board (RR 0 TEST.BTL), plus 65 reference TST00xx.TGA images. A future avenue for validating the raw iserver/link emulation and for golden-image comparison.

Validated: full render loop, clean

emulator\src\src\dosbox-x.exe -conf emulator\flyk.conf
# (VPXLOG + VPX_RESPOND=1 in the environment)

flyk.conf mounts C: at ALPHA_1, runs flyk clear.scn ..\cycle\camera.spl from \VWETEST\VGLTEST. Result — the game-independent DPL app drives the entire protocol through the emulated board with no errors:

flyk.exe clear.scn ..\cycle\camera.spl
load scene, zone=0x1307a0
fog ... / set background ... / Starting position ...
added . to USER geometry/material/texture search path
set tracking to KEYBOARD ...
hey, read the scene
Exiting rendering          <- rendered, frame-ack fired, clean exit

The device log shows the expected sync reply token handshake and a frame ack (action 9). This confirms the VPX emulation (boot → iserver handshake → i860 download → token sync → scene build → draw_scene → frame-ack → clean shutdown) is correct for an arbitrary DPL renderer, not just the game.

Configs (this directory)

flyk.conf — FLYK + clear.scn (minimal render loop). Works.
cycle.conf — CYCLE yip.scn real geometry (DOS/4GW FLYK; older sync — WIP).
alpha1.conf — full game rooted at the production image (btdpl.ini config).
rio.conf — game with the real RIO on COM1 (Phase 5, validated).
respond.conf — game with the minimal test image.

Next (Phase 3): pixels

Use flyk DIVRGB.SCN (color bars) as the first geometry target. The geometry / material / texture commands already flow over the FIFO as framed messages (vr_create, vr_set_geom_verts (22), vr_set_texmap_texels (23), vr_list_add, vr_draw_scene). Phase 3 decodes those payloads — the same DIV-BIZ2 vertex/material formats already implemented in restoration/divformats.py — into an OpenGL backend and presents to a window, turning the emulated board's frame into actual pixels.

3.5 KiB Raw Blame History