That's similar very to what I'm doing with my engine too! I didn't do much research before I started coding and representing the board with an array of 64 squares of pieces was so intuitively obvious I didn't even consider that there could be better alternatives. First I just wrote everything out in code and then I generalized all the for loops and checks for the end-of-board into lookup tables and got a nice speed gain and much clearer code. And you can use the same lookup tables to figure out if squares are attacked by specific pieces! I do that to find out if castling is possible and for testing if a king is in check.jstanback wrote: ↑Thu Mar 04, 2021 6:31 pmMy favorite mailbox move generator uses a 64 square board and has a pre-computed table of Moves of 64x10x10 = 6400 bytes which is indexed by square and direction. The directions are N,S,E,W,NE,SE,NW,SW,Knight,and King. For each square and direction the table has a list of squares in that direction which is terminated by a value OFFBRD. To generate the moves for a bishop on square b2 and add them to mvlist, the move generator calls:
And so forth for the other pieces. I think I had one Scan function for captures and another for non-captures.
For me (a long time ago) this generator was as fast for Perft() as my 0x88 and faster than my bitboard generator and I liked that it used a 64 square board so that I could use a hybrid of mailbox and bitboard functions until I got more comfortable with bitboard stuff. I had piecelists for each color and piecetype which was faster and easier for making/unmaking moves than having one piecelist for each color.
I'm just not having any piecelists. I can see that it would make sense to know the kings positions without having to go over the entire board, but why is it good to know where the other pieces are? Did you use that in your evaluation function or something?