2 ms·

Nice! Though there are max 32 pieces on a board, not 16; so this scheme is 64 + 32 * 4 = 192 bits, or 24 bytes. The bit to indicate whose turn it is isn't acco

Nice! Though there are max 32 pieces on a board, not 16; so this scheme is 64 + 32 * 4 = 192 bits, or 24 bytes. The bit to indicate whose turn it is isn't accounted for here. But it probably could probably represented by the binary negation of the bitboard -- if there are 32 or fewer bits set, then it is white's turn; if there are 33 or more bits set, then it is black's turn and you can negate the bitboard prior to determining which squares are occupied. Taking things further, it probably can be compressed even more with (much) more complex logic, as the castling available bit must only be present on the corner positions, and the pawn en-passant capabilities are only available on the middle rows, so those bits are meaningless in other positions.

penteract 3y ago
> if there are 32 or fewer bits set, then it is white's turn; if there are 33 or more bits set, then it is black's turn and you can negate the bitboard prior to determining which squares are occupied. This doesn't quite work because if there are exactly 32 bits set, inverting it leaves 32 bits set. You could fix this by marking all pawns belonging to the player who's turn it is as capturable via en-passant (if a player has no pawns left, at least 1 piece has been captured, so inverting the bitboard works).
- sufianrhazi 3y ago
  Oh you're right, nice catch!
- LorenPechtel 3y ago
  Now you have me thinking of bughouse chess.
timerol 3y ago
I like the bitboard inversion idea. (Requires flipping logic as well from https://news.ycombinator.com/item?id=37526484 https://news.ycombinator.com/item?id=37526484, since 32 is a special case.) Note that the en-passantable pawns and castle-able rooks came from options that were unused in my first pass (linked comment). I could use 0x1 as "castleable rook or en-passantable pawn, determined from where it is" and then store 32 integers with 13 options in 119 bits[1], saving 9 bits. But I'm kinda attached to the simplicity here. (The 16->32 was edited as you wrote this comment.) [1] log(13^32)/log(2) = 118.4
6510 3y ago
There is never a pawn at the 8th row, one might "insert" an en-passant row into the board.

penteract 3y ago

> if there are 32 or fewer bits set, then it is white's turn; if there are 33 or more bits set, then it is black's turn and you can negate the bitboard prior to determining which squares are occupied. This doesn't quite work because if there are exactly 32 bits set, inverting it leaves 32 bits set. You could fix this by marking all pawns belonging to the player who's turn it is as capturable via en-passant (if a player has no pawns left, at least 1 piece has been captured, so inverting the bitboard works).

sufianrhazi 3y ago
Oh you're right, nice catch!
LorenPechtel 3y ago
Now you have me thinking of bughouse chess.

timerol 3y ago

I like the bitboard inversion idea. (Requires flipping logic as well from https://news.ycombinator.com/item?id=37526484 https://news.ycombinator.com/item?id=37526484, since 32 is a special case.) Note that the en-passantable pawns and castle-able rooks came from options that were unused in my first pass (linked comment). I could use 0x1 as "castleable rook or en-passantable pawn, determined from where it is" and then store 32 integers with 13 options in 119 bits[1], saving 9 bits. But I'm kinda attached to the simplicity here. (The 16->32 was edited as you wrote this comment.) [1] log(13^32)/log(2) = 118.4

6510 3y ago

There is never a pawn at the 8th row, one might "insert" an en-passant row into the board.