This is my move generator code for black. Its insanely buggy, please help me find those bugs. I've fixed parts of white move generator code, but Black's movegen code is still buggy. So just not to confuse you guys, I've only posted White movegen code.
1. When you code a bitboard generator like this, verify and verify about knights before moving to another piece type. Knight is the easiest because it isn't sliding. Are you sure your knight generation is correct? If not, focus only and only on it.
2. You don't need code for both colors. You should define a function for generation for each piece type. The function takes a color.
3. What's Bitboard::whiteKnights??? Is this a static bitboard? If this is static, how can you play a game?
Instead of debugging it for you. I'll advise you to do the following:
A. Write a function that generates a bitboard for a knight attacks for each square.
B. Write and test a function that returns a list or a bitboard of all knights from any FEN position.
Once you've done A and B. You can easily generate pseudo-knight moves by looping through each knight square. Please proceed only if you're confident your knight generation is correct.
1. When you code a bitboard generator like this, verify and verify about knights before moving to another piece type. Knight is the easiest because it isn't sliding. Are you sure your knight generation is correct? If not, focus only and only on it.
2. You don't need code for both colors. You should define a function for generation for each piece type. The function takes a color.
3. What's Bitboard::whiteKnights??? Is this a static bitboard? If this is static, how can you play a game?
Instead of debugging it for you. I'll advise you to do the following:
A. Write a function that generates a bitboard for a knight attacks for each square.
B. Write and test a function that returns a list or a bitboard of all knights from any FEN position.
Once you've done A and B. You can easily generate pseudo-knight moves by looping through each knight square. Please proceed only if you're confident your knight generation is correct.
Hi!
1. The Knight Move generator is the most correct one in my program, weird enough. The more buggy parts are pawns.
2. Yes, I have. I just posted this to not confuse you guys, as I mentioned.
3. Bitboard::whiteKnights stores white knights on the board, and so does Bitboard::whitePawns, Bitboard::whiteQueens etc.
A. I use this function to generate arrKnightAttacks:
The earlier comment with regard to Bitboard::whiteKnights was motivated by it being strange syntax (and i'm not sure if it's correct or not to be honest). Usually you would only use class::member to access a variable if a) you're not operating in the namespace already anyways (which you are because this is a member function) and b) member is declared static. since the function you're in is part of Bitboard:: already you can access the whiteKnights variable without any qualifier. And if it's not a static member (which i assume it shouldn't be in the event you ever want to have more than one copy of the class), to access it outside of the class you'd need to use 'variable.whiteKnights'.
Pawns and knights should be straightforward to debug. The cases you need to watch out for are where the square differences cause the board to wrap (what happens when a pawn on h3 tries to capture to the right). A note on your pawn generation: rather than looping through all pawns and individually testing for unoccupied/enemy occupied squares the normal way to generate pawn moves is in batch for each case (capture left, capture right, single push, double push), and then loop through the result of pawns that can execute the move in question.
As for your sliders, i'd recommend NOT using magics for your first move generator due to reliance on large data tables that are a pain to debug manually. One simple way to generate a slider attack is to use either bitscan forward or bitscan reverse on (ray & (occupied | perimeterofboard)) depending on direction to find your first blocker in each direction and just return the path between each pair of blockers, much simpler to debug. You can later switch to magics if you want and use the simpler move generator to do automatic testing of your mass of magic numbers.
kbhearn wrote:The earlier comment with regard to Bitboard::whiteKnights was motivated by it being strange syntax (and i'm not sure if it's correct or not to be honest). Usually you would only use class::member to access a variable if a) you're not operating in the namespace already anyways (which you are because this is a member function) and b) member is declared static. since the function you're in is part of Bitboard:: already you can access the whiteKnights variable without any qualifier. And if it's not a static member (which i assume it shouldn't be in the event you ever want to have more than one copy of the class), to access it outside of the class you'd need to use 'variable.whiteKnights'.
Pawns and knights should be straightforward to debug. The cases you need to watch out for are where the square differences cause the board to wrap (what happens when a pawn on h3 tries to capture to the right). A note on your pawn generation: rather than looping through all pawns and individually testing for unoccupied/enemy occupied squares the normal way to generate pawn moves is in batch for each case (capture left, capture right, single push, double push), and then loop through the result of pawns that can execute the move in question.
As for your sliders, i'd recommend NOT using magics for your first move generator due to reliance on large data tables that are a pain to debug manually. One simple way to generate a slider attack is to use either bitscan forward or bitscan reverse on (ray & (occupied | perimeterofboard)) depending on direction to find your first blocker in each direction and just return the path between each pair of blockers, much simpler to debug. You can later switch to magics if you want and use the simpler move generator to do automatic testing of your mass of magic numbers.
I find magics simpler to understand. But I'd surely work on your advice.
vittyvirus wrote:This is my move generator code for black. Its insanely buggy, please help me find those bugs.
One day I might use bitboards, and maybe even understand "magic" bitboards. For now, I use an array of 130 (thought of as 13 x 10) ints for my board representation. (It's a 12 x 10 scheme, with an extra "rank" that holds state information and king locations.) After two weeks of writing and debugging (twice finding = where I intended to have ==), I seem to have a working (legal) move generator:
vittyvirus wrote:This is my move generator code for black. Its insanely buggy, please help me find those bugs.
One day I might use bitboards, and maybe even understand "magic" bitboards. For now, I use an array of 130 (thought of as 13 x 10) ints for my board representation. (It's a 12 x 10 scheme, with an extra "rank" that holds state information and king locations.) After two weeks of writing and debugging (twice finding = where I intended to have ==), I seem to have a working (legal) move generator:
vittyvirus wrote:This is my move generator code for black. Its insanely buggy, please help me find those bugs.
One day I might use bitboards, and maybe even understand "magic" bitboards. For now, I use an array of 130 (thought of as 13 x 10) ints for my board representation. (It's a 12 x 10 scheme, with an extra "rank" that holds state information and king locations.) After two weeks of writing and debugging (twice finding = where I intended to have ==), I seem to have a working (legal) move generator:
vittyvirus wrote:This is my move generator code for black. Its insanely buggy, please help me find those bugs.
One day I might use bitboards, and maybe even understand "magic" bitboards. For now, I use an array of 130 (thought of as 13 x 10) ints for my board representation. (It's a 12 x 10 scheme, with an extra "rank" that holds state information and king locations.) After two weeks of writing and debugging (twice finding = where I intended to have ==), I seem to have a working (legal) move generator: