- vpxlog.cpp: VPX_FIFODUMP=<path> records every FIFO burst ('VPXM' records)
- decode_fifodump.py: action census + payload dumps of a capture
- render_capture.py: reconstruct the DPL scene graph from a capture and
software-render each draw_scene frame (camera, view, materials, geometry
all taken from the wire)
- divrgb.conf + divrgb.fifodump: flyk divrgb.scn capture fixture
- divrgb-decoded.png / divrgb-frame0.png: first images ever produced from
the Rel 4.10 VPX protocol without a real board -- the textbook SMPTE
color-bar pattern, validating verts/conns/materials/camera in one shot
- PHASE3-PROGRESS.md: the established Rel 4.10 wire protocol (action map,
node types, message layouts); RENDER-HARNESS.md updated
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.4 KiB
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-basedvelocirender_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 fromDIVISION/*.BGF),DIVCAL.SCN.CYCLE/— a full render-cycle test:flyk yip.scn camera.splrendering real Red Planet geometry (REDPLANT.BGF) with dynamic objects and events. NOTE: this FLYK is a DOS/4GW build using the older DPL3-stylevelocirender_sync(action-check, not token) — it currently hitsunexpected action 1 in velocirender_syncagainst 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 INMOSISERVER.EXEto boot aTEST.BTLonto the board (RR 0 TEST.BTL), plus 65 referenceTST00xx.TGAimages. 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— CYCLEyip.scnreal geometry (DOS/4GW FLYK; older sync — WIP).alpha1.conf— full game rooted at the production image (btdpl.iniconfig).rio.conf— game with the real RIO on COM1 (Phase 5, validated).respond.conf— game with the minimal test image.
Phase 3a: pixels (DONE — see PHASE3-PROGRESS.md)
flyk DIVRGB.SCN was captured with VPX_FIFODUMP (divrgb.conf →
divrgb.fifodump), the full Rel 4.10 FIFO message set was decoded
(decode_fifodump.py), and the captured frame was reconstructed to pixels
(render_capture.py → divrgb-decoded.png): the textbook SMPTE color-bar
pattern, drawn entirely from the wire protocol. Phase 3b is the live OpenGL
backend inside DOSBox-X.