Use a better condition to find candidate direct check pawns.
In particular consider only pawns in the front ranks of the
enemy king, this greatly reduces pawns candidates bitboard
that now is empty more then 90% of the time so that we
can early skip further tests.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Be more strict, is not enough dc bitboard is not empty, but
needs to inclde also at least one pawn.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
We can parametrize for the capture direction too.
Also use a single template parameter and calculate (at
compile time) remainin parameters directly in the function.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In case we have a correct white pawn move but pawn
is black (or the contrary) we fail to detect the
move as illegal.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Instead of loop across all legal moves to find a mate
loop across possible check moves only.
This reduces more then 10 times the number of moves to
check for a possible mate.
Also rename generate_checks() in generate_non_capture_checks()
so to better clarify what the function does.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Avoid calculating piece attacks if there aren't
available check sqaures for the given piece.
About 15% of cases. Not a biggie but still something
especially in the middle game where king is well covered
inside his castle.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
It is slower the previous uglier but faster code.
So completely restore old one for now :-(
Just leave in the rework of status backup/restore in do_move().
We will cherry pick bits of previous work once we are sure
we have fixed the performance regression.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
They hide the underlying uniform function call with
no benefit.
A little bit more verbose but now is clear what happens.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
In generate_piece_moves() to be more uniform with other
functions. Unfortunatly the different number of calling arguments
do not allow us to easily integrate in generate_piece_moves()
template family.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Small code tidy up and a little optimization
to avoid calling generate_piece_blocking_evasions()
when blockSquares is empty (30% of cases).
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Now that we have removed sliders checkers attacks
from evasion's set we can simplyfy legality check.
No functional change.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Rewrite as in generate_piece_moves() using a for
loop instead of the slower serializing of the
bitboard with pop_1st_bit()
This will allow also to merge with generate_piece_moves()
when we will drop legality constrain on generate_evasions()
Generated moves are not changed, but are generated in a
different order, this changes the number of nodes at fixed
depth test.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Discovery check candidates are normally empty, so
avoid discovery checks generation in that common case.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Find squares attacked by slider checkers, we will
remove them from king evasions set so to avoid a couple
of cycles in the slow king evasions legality check loop.
Not a biggie, but now generate_evasions() is faster then
generate_non_captures(), before was slower.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
When we generate checks one case is missing: generation
of castling moves that give check to the opponent king.
This is a very rare case but anyway it is a case
and we can do this without slowing down the common
case of no castling checks.
So this is the patch.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Introduced in the patch "movegen: prefer (*mlist++) to mlist[n++]"
This was nasty because due to a mismerge the repo in one PC had the bug,
but the testing one did not, so I had non reproducible results according
to which machine I used for testing.
This hopefully closes a more then one week regression that made me go crazy!
It was found by accident comparing, for other reasons, the sources of the
two PC's.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Use the pinned argument in pos.move_is_legal()
No functional change, simply use pos.move_is_legal() as
was meant to be.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Introduced in "movegen: Introduce generate_pawn_captures()"
when unifiying black and white functions.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>