Author: Gerd Isenberg
Date: 03:28:24 09/21/04
Go up one level in this thread
On September 21, 2004 at 02:15:34, Tony Werten wrote:
>On September 20, 2004 at 18:17:36, Gerd Isenberg wrote:
>
>>Looking back to Steffan Westcott's great posts about
>>"Natural move generation with bitboards"
>>
>>http://chessprogramming.org/cccsearch/ccc.php?art_id=266455
>>http://chessprogramming.org/cccsearch/ccc.php?art_id=266676
>>
>>with the idea to generate disjoint direction-wise attacks for each piece type
>>inside a fixed sized structure.
>>
>>For white/black pawn bitboards we need only two attack directions by simply
>>shifting all pawns per side by 7 or 9 in the appropriate direction, considering
>>board wraps performing the usual notA- or notH-masks before or after shifting.
>>Both target bitboards may be "anded" to get double pawn attacks or may be "ored"
>>to get pawn-attacks independent of the direction.
>>
>>If we traverse pawn targets direction-wise, anded by opposite pieces to generate
>>pawn captures, the source square of a target is simply determined by shifting in
>>the opposite attack direction. Or in move-square metrics instead of bitboard
>>metrics one may add/sub 7 or 9.
>>
>>Steffan suggested to do similar technique with sliders using Kogge-Stone fills
>>for each sliding piece type too. With the advantage to generate multiple pieces
>>per direction once, for all straight or diagonal sliders, possibly combining
>>queen and rooks or queen and bishops. Even if there is a unique relation between
>>one target and source square per direction, it is, compared to pawns captures,
>>not that easy to map the target to the source square for sliders. Indeed, as
>>Steffan mentioned, a fill in the opposite direction with a single isolated
>>target square is required to determine the unique source square by "and".
>>
>>Specially for ALL-nodes a lot of additional fill stuff to do, which IMHO is
>>worth to avoid by better keeping disjoint piece attacks for sliders as well.
>>Piece-wise attacks is IMHO also important for eval, looking for trapped or
>>immobile pieces.
>
>I haven't really optimized this yet.
>
>What I do now is take the rooks/queens. Generate all 4 rook directions, and it
>with opponent pieces. The for each attacked piece, generate the 4 rook
>directions, and see where it hits its attacker.
>
>Fast if there are no attcks, but double work if the are.
>
>Doing the directions one at a time, might save time, at the extra cost of 4 test
>( wether the attacked pieces bitmap is not empty)
I see. I keep for each sliding direction the intersection of all sliding attacks
with the opposite direction meta-king "attacks".
interSlideKing[left][side] =
slideAttacks[left][side] & kingMetaSlideAttacks[right][other(side)];
...
These inter-sets are usefull for
1.) determing pinned pieces by
interSlideKing[dir][other(side)] & pieces[side]
2.) determing remove checker by
interSlideKing[dir][side] & pieces[side]
3.) in case of a sliding single check on this direction,
interSlideKing is already a set of empty squares,
the target set for possible moves to interrupt the checking slider.
If interSlideKing[dir][other(side)] is != 0,
but interSlideKing[dir][other(side)] & pieces == 0,
there is always a sliding check on this direction.
>
>I have no time now to test that kind of stuff, first want my engine to play a
>decent game. ( Only still have to add kingsafety and pawnstructure, but I can
>take those from my old engine, with some rewriting ) I have a week off now, so
>maybe next week I can start to really play around with those bitboards :)
>
>Tony
Do you intend to play dutch open with your new program?
Gerd
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.