Answers.Body: <p>Move generators in modern engines do this with lookup tables, which are indexed by the square of the slider and a bitboard representing occupied (impassable) squares that might block the movement of the piece.</p>
  
  <p>There are two main ways of compressing the huge set of possible occupancy bitboards into a reasonable size. <a href="https://www.chessprogramming.org/Magic_Bitboards" rel="noreferrer">Magic Bitboards</a> are often used, which involve multiplying the occupancy bitboard by 'magic' numbers, which are chosen because they empirically map the set of possible occupancy bitboards into a dense range.</p>
  
  <p>A more modern way depends on the PEXT instruction which is available in newer x86 processors. <a href="https://www.chessprogramming.org/BMI2#PEXTBitboards" rel="noreferrer">PEXT bitboards</a> allow for the lookup table to be mapped to an even denser range, and also improves lookup times on processors which can run PEXT quickly. However, PEXT is very slow to emulate on older processors, and also <a href="http://talkchess.com/forum3/viewtopic.php?t=67432" rel="noreferrer">seems to be particularly slow on Ryzen processors</a>.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-15T13:36:11.683Z
Answers.Text: How does this bit board determine impassable squares, is it a fixed value or that it is computed for some instances of a blocking piece in a board position?
Answers.UserDisplayName: Crupeng
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-15T15:29:24.177Z
Answers.Text: It's precomputed (with the naive method of iterating over rays) and then stored in a table.
Answers.UserDisplayName: konsolas
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-02-15T12:36:58.397Z
Answers.LastActivityDate: 2020-02-15T12:36:58.397Z
Answers.UserDisplayName: konsolas
Body: <p>I currently have a function which returns the closed off squares for a piece in a particular position based on pieces blocking it. This function iterates over the rays of a piece and is sufficiently fast, but can use a lot of improvement since it accounts for most of the time taken in the move generation. </p>
  
  <p>I have been recently researching on how I can optimise this function and came across this "trick":
  <a href="https://www.chessprogramming.org/Subtracting_a_Rook_from_a_Blocking_Piece" rel="nofollow noreferrer">https://www.chessprogramming.org/Subtracting_a_Rook_from_a_Blocking_Piece</a> which conveniently uses a formula to instantly get all the moves for a rook. Is there a similar "trick" to generating moves for a bishop while accounting for the blocking pieces?</p>
  
  <p>If you need any clarifications regarding the question, feel free to ask.</p>
  
Tags: <engines><programming><bishops>
Title: Is there a method to efficiently generate moves for bishops?
ThreadText: # Is there a method to efficiently generate moves for bishops?
  
  (Asked by: username_0 on 2020-02-15)
  
  I currently have a function which returns the closed off squares for a piece in a particular position based on pieces blocking it. This function iterates over the rays of a piece and is sufficiently fast, but can use a lot of improvement since it accounts for most of the time taken in the move generation.
  
  I have been recently researching on how I can optimise this function and came across this "trick":
  <https://www.chessprogramming.org/Subtracting_a_Rook_from_a_Blocking_Piece> which conveniently uses a formula to instantly get all the moves for a rook. Is there a similar "trick" to generating moves for a bishop while accounting for the blocking pieces?
  
  If you need any clarifications regarding the question, feel free to ask.
  
  **Tags:** engines, programming, bishops
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-02-15. Score: 6 | Accepted answer
  
  Move generators in modern engines do this with lookup tables, which are indexed by the square of the slider and a bitboard representing occupied (impassable) squares that might block the movement of the piece.
  
  There are two main ways of compressing the huge set of possible occupancy bitboards into a reasonable size. [Magic Bitboards](https://www.chessprogramming.org/Magic_Bitboards) are often used, which involve multiplying the occupancy bitboard by 'magic' numbers, which are chosen because they empirically map the set of possible occupancy bitboards into a dense range.
  
  A more modern way depends on the PEXT instruction which is available in newer x86 processors. [PEXT bitboards](https://www.chessprogramming.org/BMI2#PEXTBitboards) allow for the lookup table to be mapped to an even denser range, and also improves lookup times on processors which can run PEXT quickly. However, PEXT is very slow to emulate on older processors, and also [seems to be particularly slow on Ryzen processors](http://talkchess.com/forum3/viewtopic.php?t=67432).
  
  > **Comments:**
  > **username_0**: How does this bit board determine impassable squares, is it a fixed value or that it is computed for some instances of a blocking piece in a board position?  
  > **username_1**: It's precomputed (with the naive method of iterating over rays) and then stored in a table.  
  
  ---
  
  