Devlog 0xB - Perft Testing - Continued Movegen Debugging
Devlog 0xB. Today, I made significant progress in enhancing the testing framework for my chess engine. I added a new file, tests.zig, which contains all the necessary tests to validate engine functionality. Additionally, I updated the build.zig file to support running these tests seamlessly. This ensures that any new changes can be automatically tested, streamlining the development process and reducing the likelihood of regressions.
Perft Debugging and Board Representation Fixes
Continuing the debugging of perft testing, I corrected the board square representation. Previously, there was an inconsistency in how the squares were indexed, leading to incorrect move generation. The updated mapping now correctly represents squares with a8 = 0, b8 = 1, and so on, aligning with the expected board layout.
This fix resolved several issues, including the incorrect pawn captures. The board representation error was affecting the parseFEN function, but after addressing these inconsistencies, the pawns now capture correctly.
Remaining Challenges in Move Generation
Despite these fixes, some challenges in move generation remain, particularly evident in the perft results for the kiwiPete test position. The engine is currently generating 2304 nodes at depth 2, whereas the expected result is 2039 nodes. This discrepancy means that there are still bugs in the move generation logic.
Pawn Capture Issue Analysis
One specific issue was the failure of pawns to capture diagonally on the correct squares. After fixing the board representation, this behavior improved, but further discrepancies were noted in the detailed breakdown of moves, particularly in edge cases involving pawn attacks. The attack masks were not correctly preventing wrapping captures (e.g., h2 taking a3).
This issue has been resolved, and as far as I know pawn move generation is correct and there are no wrapping captures occurring.
Next Steps
I need to take a hard look at each piece of generating a move and compare it to my C implementation. Move generation was correct there, so following a similar format should yield the same results. There are a few potential candidates that could be causing these issues. As previously mentioned, I changed the square representation to align with the bitwise operations typically used for chess move generation, and as such I may have remaining artifacts of dealing with the bitboard square that may be causing these movegen bugs.
I will continue to work on debugging these issues and I will update you with whatever I find tomorrow :)