Single Comment

I made some progress on the highlighting: the execution time of the legality test on all moves is now reduced by about an order of magnitude, typically 0.45 sec for Mighty Lion Chess. (Was 4 sec.) So I made fully-legal highlighting the default now. (Highlighting of all pseudo-legal moves can still be requested by putting set pseudo 1; in the Pre-Game code.)

What I did can best be described as 'incremental check testing'. The problem was that check-testing with potentially weird moves that turn corners and hop over pieces, the only reliable way to detect check is to generate all moves, and see if there is a king capture amongst them. Doing that after every pseudo-legal move, to decide whether it should be highlighted or not, was very expensive. All the more so because the move generator, because it has to be so general, is not very efficient; it is basically an extra interpreted level.

Now I only do such a check test once, in the position before the moves. But it is an 'augmented check test'; rather than just testing if a capture hits the king, it records potential captures (i.e. capture moves to an empty square) in a board-size table, so that you can easily test whether a king would move into check. And it records all rides that could not reach their full potential (i.e. were blocked by a piece before their range was exhausted) in a list for the square where they were blocked. And similarly, it records for each empty square what hopper moves have their pre-hop leg going over them. And if it does encounter a capture that hits the king, it records that move in a list of checks.

With the aid of that information the check test after a move becomes very simple. If a royal moves, a table-lookup tells you whether the destination square was under attack, and if it is, you reject the move immediately. Otherwise, you make the move, but instead of trying all opponent moves to see whether they hit the king, you only try the moves that were recorded for the origin and destination squares. On the origin square the list will contain all opponent moves that were blocked there in the augmented check test, and you re-run those to see how much farther they get now the square is evacuated, and if any of them manages to hit the king now. Most of the time the list is empty, because the moved piece was not attacked by an opponent slider, and in many other cases you just have to re-run one move of one piece (i.e. a ride starting in a given direction).

Similarly, the destination square will list which hopper moves would be activated by putting the piece there as a screen, and these then will also be tried in the reply. Obviously this would never be needed in a game without hoppers. If the move to test for legality is a locust capture, we also re-run the moves that were blocked by the victim (and thus discovered by its removal).

Finally, if the augmented check test finds an actual king capture, it will put that move in a list of checks. The legality test when you have to evade a check will always start with re-running those checks, to see if you have resolved them. Most moves usually won't, so it would be the only reply you have to try in order to conclude you remained in check, and reject the move as illegal.

The current code still takes significantly longer running time when the side to move is in check, but this is not due to the highlighting, but due to the mate test, which still used the old system, which does try all replies to a move. But that stops on the first legal move it finds, which is usually the first move it tries when you are not in check to begin with. But when you are in check it has to try many moves before it hits upon a legal evasion. (And when it is really mate, it would try them all to no avail.) So I think I will replace that test by the new method too, combining the highlighting and the mate test.