More informative between_bb #976
Description
A simple idea for code improvement and a step towards more logical handling of check detection:
Why not also indicate the paths of oblique riders in the BetweenBB table? As far as I could see between_bb is now only called after establishing that the arguments are connected by a Queen move, so the elements that are not on those are never accessed at all. E.g. BetweenBB[SQ_A1][SQ_G4] could easily be initialized with the path c2, e3, g4 for indicating the Nightrider path between the two.
The Nightrider is currently stigmatized as a NON_SLIDING_RIDER, but it isn't really different from a slider like R or B: it visites all squares that are exactly on the path between origin and destination, and ignores all other squares. So it should not need special teatment in check or evasion detection: the squares a King can reach through Nightrider moves are the square where a Nightrider would check when it lands there, and pieces landing on the squares the Nightrider then passes exactly through would block the check. (This unlike Alfil- and Dabbabariders, which jump over some squares of the connecting ray, and cannot be blocked there.) The only reason for making the 'target' equal to the entire board rather than the checking ray during evasion generation seems to be that between_bb does not contain the Nightrider paths. If it did, there would be no reason to label the Nightrider as non-sliding.
The same holds for Camel- and Zebrariders, once implemented. BetweenBB[s1][s2] could simply mark all squares exactly on the line from s1 to s2, for any pair s1,s2 (plus s2).
Note that between_bb(s1, s2, pt) could be extended to also give the squares where Alfil- or Dabbabariders can be blocked on their path from s1 to s2, which is only a subset of what between(s1, s2) would give. The 'target' for evasions could then be set to those, in case an AA or DD would check, and there would also be no reason to not use normal evasion generation for those.