summaryrefslogtreecommitdiff
path: root/src/save/root.c
diff options
context:
space:
mode:
authorScott Gasch <[email protected]>2026-09-05 10:01:41 -0700
committerScott Gasch <[email protected]>2026-09-05 10:01:41 -0700
commit1216f4e159af037a32323aa7c942e64fcecafb05 (patch)
tree35ce97e6663914075aa644d0801cdf08184ee65d /src/save/root.c
parentd184a2ea4314d6bd4b8933482c0c1e7a420f2872 (diff)
Queen attack/mobility: bitboard rewrite (two-pass rook/bishop lookups); fix rook/bishop mobility to credit squares beyond a battery partner
_EvalQueen's mobility ray-walk and QMobCaseTable switch replaced with two passes of the same unified chain-walk technique rook/bishop use -- _RookAttacksBB for the orthogonal-direction pass, _BishopAttacksBB for the diagonal-direction pass (MOVEGEN_MIGRATION.md/EVAL.md already established a combined 8-ray table measures slower than reusing the rook/bishop tables separately, per the stashed first bitboard-eval attempt's _EvalQueenOccupancyBB PoC -- reused that structure instead of rediscovering the regression). Continue-set per pass: friendly queen in both, friendly rook only in the rook-direction pass, friendly bishop only in the bishop-direction pass -- QMOB_FRIEND_ROOK/_BISHOP's old fOrthogonalRay flag is entirely subsumed by which lookup a blocker shows up in. Queen never x-rays through any enemy piece (unlike rook/bishop), so each pass's continue-set has no enemy side. Adds pos->bbQueenAttacks[2]/bbQueenXrayAttacks[2] and the corresponding _IsSquareAttackedByQueen/_IsSquareXrayedByQueen transitional helpers (DEBUG-cross-checked against an independent mailbox walk, same pattern as the rook/minor helpers), with _WhoControlsSquareFast and _EvalKing's bvAttack/bvXray/bvDefend/uQueenNearKing computations updated to read them instead of the old per-square bvAttacks bits queen no longer writes. Also fixes a real, previously-unnoticed fidelity gap in the already-committed rook and bishop conversions: the old mailbox walk doesn't just x-ray past a friendly battery partner (or, for rook/ bishop specifically, an x-rayable enemy queen/king) for attack-bit purposes -- it keeps walking and keeps crediting *mobility* for whatever safe/empty squares and further captures lie beyond, however many such blockers are stacked on one ray. The originally-committed bitboard versions only ever computed mobility from the near side (up to the first blocker via the magic lookup) and treated the chain purely as an attack-bit population exercise. Caught by direct comparison against the pre-conversion mailbox binary on battery positions (rook: two same-color rooks on an open file, old code credited 13 mobility to one rook via squares beyond its companion vs. 9 for the near-side-only bitboard version; bishop: two same-color bishops on one diagonal, 12/8 old vs. 11/5 near-side-only). Fixed by merging each piece's mobility and x-ray-population computation into a single chain-walk that credits mobility at every layer, not just the first -- queen's own conversion was written with this fix in from the start and verified against the same kind of battery position (two queens on a file, queen+rook, queen+bishop) before landing. Verified via precommit_check.sh (self-test + DEBUG smoke test, several hand-built multi-piece-battery positions run directly against a DEBUG binary to exercise the new cross-checks) after each step. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01XxmVi2sTMwpPp4i6WYFjan
Diffstat (limited to 'src/save/root.c')
0 files changed, 0 insertions, 0 deletions