nx_fx.nx

fx.nx -- deterministic Q16.16 fixed-point math. Why fixed-point and not IEEE-754 float: Rollback netcode (GGPO 2006, Skullgirls, Killer Instinct) requires bit-identical simulation across machines. IEEE-754 + Math.sin cannot deliver this -- different JS engines (V8, SpiderMonkey, JavaScriptCore) ship different sin/cos implementations, and even addition order can diverge under JIT inlining. Fixed-point integer math is the only way to guarantee "same input → same bits on every machine." Representation: Q16.16 - 64-bit signed integer: high 16 bits integer part, low 16 bits fractional part. Negative values use two's complement. - Range: ±32767.99998... blocks. Precision: 1/65536 ≈ 15 μm at 1 m = 1 block. Adequate for voxel games, physics, gameplay sim up to ~32 km arenas. Invariants (enforced, not hoped): FX1 No IEEE-754 anywhere. NishiLang has no float type today, so this is trivial -- but if floats ever land, fx.nx does not use them. FX2 fx_mul and fx_div round toward zero (arithmetic shift, not round-to-nearest). Deterministic and simple; callers needing round-to-nearest do `(a + (b >> 1)) / b` explicitly. FX3 sin/cos via CORDIC algorithm -- 16 iterations, ~Q16.16 precision, no Math.sin dependency. Converges through a precomputed atan table. Every implementation (NishiVM, native C VM, future Nishi silicon) produces bit-identical results by construction. FX4 Overflow in fx_mul is possible if both operands exceed 16-bit integer range. Callers are responsible for clamping; we do NOT implement saturation arithmetic by default (silent saturation masks bugs; explicit clamp is better). References: - Volder 1959, "The CORDIC Trigonometric Computing Technique" - Kota-Kuroda-Shimamura 1989, "A High-Speed Fixed-Point Multiplier Using Carry-Propagation-Free Adders" - GGPO 2006 whitepaper (rollback determinism rationale)