diff options
| author | Scott Gasch <[email protected]> | 2026-09-05 10:01:41 -0700 |
|---|---|---|
| committer | Scott Gasch <[email protected]> | 2026-09-05 10:01:41 -0700 |
| commit | 1216f4e159af037a32323aa7c942e64fcecafb05 (patch) | |
| tree | 35ce97e6663914075aa644d0801cdf08184ee65d /src/save/root.c | |
| parent | d184a2ea4314d6bd4b8933482c0c1e7a420f2872 (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
