Reconstruction direction

Agreed direction, 23 September 2026. Both implementation stages need separate planning; neither is started by the extraction work.

1. Faithful reconstruction first. Readable modern C++ (C++23/26 as appropriate), accessing the existing game assets and reproducing original drawing logic and gameplay behaviour. Preserve fixed-point arithmetic, integer widths, wraparound, timing and state dependencies. Standard library facilities, objects, references, templates, arrays and spans should express recovered behaviour without silently replacing it with different semantics. Original pack access remains part of this stage; extracted assets are analysis/reference material, not a prerequisite replacement format.
2. Browser re-engine afterwards. Use extracted/converted modern assets, with dynamic window sizing, configurable controls, adjustable fog and other visual properties. Plan the browser/WASM and rendering architecture separately, informed by the faithful reconstruction. Rendering-backend and software-renderer choices remain open.

For present extraction and analysis, retain source bytes and offsets, identify consumers and field meanings, distinguish observed behaviour from hypotheses, and check translated effects against original instructions where practical. Preserve known uncertainties. The embedded mission setup analysis illustrates why this matters: state includes carry-dependent helper inputs, patches to subsequent records and even patches to instruction immediates. A readable implementation can express these as ordinary operations once their ordering and effects have been established.

Full mission scheduling, compact route behaviour and all runtime handler semantics remain future analysis work. The Python reference operations used for differential checks are analysis tools, not the start of either engine implementation.