ea99e8987f15cb290acdde93135aa7d8cf991332
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  CydandClaude Fable 5
|
0e763fda1f |
BT410 5.3.113: the displays lag because the loop is slow, and the loop was slow because the flags were wrong -- authentic OPT.MAK optimizer set adopted
The operator's 'many seconds between display updates', run to ground: MECHANISM (verified in source AND the shipped exe bytes): main passes GetTicksPerSecond() as ApplicationManager's frame RATE, so frameDuration is microscopic and RunMissions runs flat-out -- exactly ONE background slot per loop frame, shipped and ours alike (ctor constant @0044f2d8 == 1.0f, read straight out of BTL4OPT.EXE). That slot feeds a 7-task ring; the gauge renderer gets 1/7th of slots, one ACTIVE gauge per slot, and the screen blits once per completed wheel pass. The wheel is 136 gauges -- and the BT_GAUGE_LOG roster dump shows all 136 are real cockpit instruments (26 armor colormappers, leak gauges, cooling loops, weapon clusters...): a Tesla pod shows everything at once, so the roster is AUTHENTIC and must not be trimmed. Per-instrument latency is therefore 7 x 146 / loop_fps -- the loop rate is the only lever. THE DEFECT: build410.sh compiled -O2 alone. The authentic release tier (CODE/BT/OPT.MAK) is -O2 -Ot -Oc -Og -O -Ol -Z -Ob -Oe -Oi -Om -Op -Ov. Adopting it (all 234 TUs clean, no BC4.52 optimizer ICEs) doubled the loop: 16.7 -> ~30 fps wall on the rig. Shipped fifo throughput is still ~2x ours (11.8KB/s vs 6.4KB/s, governor-conflated) -- residual gap is an open question pinned in GAUGE-CADENCE-NOTES.md with the operator A/B ask. Instrumentation kept, cheap and gated: slot/wheel counters on the [stack] line (BT_STACK_LOG), one-shot roster dump (BT_GAUGE_LOG), tick-delta timers compile-gated BT_TICK_PROBES (OFF -- guest tick sums proved to be trap-burst artifacts in the emulator, not costs; wall rates are the only trustworthy measure). New: MUNGA/APPTASK.CPP shadow, fifofps.py (true board fps from a fifodump), pod_render_bgprobe.conf. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
d3b332a62a |
BT410 5.3.58: the load gate is blocked by a REFILL loop on priority 0, not starvation
Per-priority occupancy, measured every second until the fault: [queues] p0=BUSY p1=- p2=BUSY p3=- p4=- nextReady=1 That single line kills the two leading theories. p3/p4 empty means nothing above priority 0 is competing, so the pump is free to serve it -- no starvation. nextReady=1 means PeekAtNextEvent always has a READY event, so priority 0 is not holding a timed event whose alarm never comes due -- no deadlock. What remains is refill: priority 0 is replenished as fast as the pump drains it, ~143 events per simulated second. It is also fully deterministic. Two runs of the same binary reported pump=352/1499 at frame 1001 and 495/2643 at frame 2002, identical to the byte. So 'crashes about half the time' was never a race -- it was comparing runs that differed in binary or conf. Only InterestManager::PostRendererEvent posts at priority 0 (it maps every renderer event there while the app is not RunningMission), so naming the message names the flooder. Application::Post now tallies priority-0 posts by message ID and reports the busiest three. Notably, all three producers of NotifyOfNewInterestingEntity are entity-CREATION paths, so if that ID dominates then something is creating entities in a loop -- which would explain the unbounded growth behind the fault as well as the hang. pod_render_noskl.conf now carries the same probes, so one instrumented binary can be run with the skeleton walk on and off. Walk-off runs are the only configuration of ours known to reach 'Turning Plasma Score Display On'. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
4cf09917ce |
BT410 5.3.57: the crash is deterministic, and the real blocker is the load gate
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> |
||
|
CydandClaude Fable 5
|
09192367c0 |
BT410 5.3.51: THE 3-D WORLD RENDERS -- reconstruction to emulated board to a picture
emulator/render-bridge/first-3d-frame.png: the arena from the pod -- sky, horizon, ground, the arena structures along the skyline -- at ~31fps on the VelociRender bridge. The whole chain now works in our build: MakeVideoRenderer -> BTL4VideoRenderer over DPLRenderer -> board boot -> Renderer::LoadMission -> DPLReadEnvironment for the art paths -> 40/40 arena objects loaded -> mission launch -> per-frame submission over the wire. The mistake worth remembering: the run was never stalled after InitializePlayerLink. I called that from a 150-second sample and it was just too short. CheckLoadMessageHandler reposts every second and will not advance until the min-priority event queue drains, and with the video renderer in the mission that takes minutes. A BT_LAUNCH_LOG trace showed the queue draining and then both RunMissionMessageHandler calls, the plasma display, and the first sensor tick -- matching the shipped binary line for line. The renderer deliberately holds a blank screen until RunningMission (L4VIDEO.CPP:5100), so 'black' was the app still loading, not a rendering bug. Zero unbuildable entities, zero geometry failures. The frame is static only because the mech is parked with no input, and the camera in the bridge title is the bridge's own viewer, not the game's eyepoint. Also banked the launch-gate trace (BT_LAUNCH_LOG) behind an env var. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|
CydandClaude Fable 5
|
af80d52e22 |
source410: engine COMPLETE (165/165) - link reaches PE emission; deep ledger cut
The tlink32 campaign after the checkpoint: eleven engine bodies back-dated from BT412 (rotation player team explode dropzone terrain cultural receiver subsystm app l4gauge - the Application core included), the WinTesla-ectomy handled by backdate.py's new unwrap rules (accessor-fn statics -> 1995 static objects, decl rewrites, pointer->reference Derivation ctor, 2007 windowed- gauge/console-marshal/idle-pump excisions), staged statics TUs opened for the game classes (MECH/BTPLAYER/BTDIRECT/PROJTILE/MISSILE/BTL4MPPR .CPP + L4APP/ NETWORK engine statics). State: every compiled symbol short of the shallow graph RESOLVED (the 52- and 17-symbol ledgers burned to zero); with 32stub.exe in place the linker reaches full vtable closure and emits the deep ledger (~210 symbols, UNRESOLVED- LEDGER.txt): remaining engine bodies (objstrm cstr gauge/gaugrend graphics pixelmap palette resfile ray scnrole explosion-table), the DOS driver extern layer (_SVGA*/_PCSerial*/_PCSPAK*/joystick/netnub/sosMIDI), the full L4App body, and the real game-TU frontier (Mech::Make et al.). Recipe proven for every category. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |