Add support for FRC (By simplifying move.c)

[andygrant]

Add support for FRC (By simplifying move.c)

[lucasart]

I can do that if you want. I have a clear idea on how to do this right (effectively making chess a particular case of chess960, rather than hardcoding chess, then adding horrible kludge to make chess960 work, which is what noobs do).

[AndyGrant]

If you would like. My plan was to provide a per-board CastleMasks array which is updated each game of chesss960 that is played. I have to different printMove type functions, so those both need to be wrapped to output castling in 960. Remaining question is how to validate castle moves. Sounds like it would require you to iterate over the squares from the king to the destination and check `squareIsAttacked``, instead of just checking one square.

[lucasart]

i propose to do it in steps:

• first you absolutely need to show perft(d-1) whe computing perft(d). It's the only way to debug (if you see a perft error at depth d, you find the bug in only d-1 iterations).
• second, add a single bitboard marking all castlable rooks. this can be debugged easily: verify at run time the coherence between the new mask and the old.
• get rid of the old mask, and modify move generation accordingly, as well as the display code (FEN and UCI move I/O). moves have to be encoded as KxR for castling.
• validate, using perft, and "perft descent" with normal positions
• add FRC positions and repeat
• only then look at raw speed, and how to improve.

PS: For validation you already have this problem in normal chess. Demolito has a nice solution, which is to always compute squares attacked by enemy. Saves this work, and saves time by avoiding to generate king moves that land on an attacked square. Note that attacked squares have to see through the checked king when in check for this to work.

[AndyGrant]

first you absolutely need to show perft(d-1) whe computing perft(d). It's the only way to debug (if you see a perft error at depth d, you find the bug in only d-1 iterations).

Sounds good. I had talked about this just the other day.

second, add a single bitboard marking all castlable rooks. this can be debugged easily: verify at run time the coherence between the new mask and the old.

Should be easy. Like the idea

get rid of the old mask, and modify move generation accordingly, as well as the display code (FEN and UCI move I/O). moves have to be encoded as KxR for castling.

Okay. I bet the bitboard mask would actually be faster. How do you plan on using this bitboard for updating the zorbist keys? Also, I'm not too aware of the notation for FRC. Finally, need to think about where using this new definition of castling (king captures vs king moves) will have an effect. Although a bench will show this, I expect.

As for the rest of the bullets, sounds good.

For the final point ... what if we have a bitboard of the squares between the king start and the king end (So for normal chess, just 1 bit sit). We pop each bit off and check if it is attacked. This will cause (almost) no slowdown in regular chess. In FRC, a couple calls to squaresAttackedBy, or whatever I called it, is costly, but I don't care for FRC.

[lucasart]

There's an extra case that hapens only in FRC. Self check through the rook! For example Ra2 castles with Ke1. If black has a Ra1, then move is illegal.

[lucasart]

typo Rb1

[AndyGrant]

Currently Ethereal applies and then validates moves. I've tried doing the more resonable...
if (!moveIsLegal(board, move)) continue, but never found any speedups.
So the above case is covered in the existing form, If I understand correctly.

[lucasart]

How do you plan on using this bitboard for updating the zorbist keys?

Easy, xor diff the castlable rooks bitbboards, and loop:

diff = after ^ before
while (diff) {
    key ^= ZobristCastle[poplsb(diff)]

most of the time, diff is zero, and the loop is free.

[AndyGrant]

ed4fe7a