H. G. Muller wrote on Sun, Aug 2, 2020 09:37 PM UTC:
I have advanced one more phase already. For one, I added some multi-leg capability to the move generator, namely the case where this is 'transparent' (i.e. without side effects). So the recursive calls to NextLeg are in place. This makes hoppers and bent riders work. Like their single-leg counterparts, such moves are also fully defined by the origin and destination square, and can be further processed in the same way. Therefore this was a quite trivial change. E.g. for handling the hoppers the code
if & 16 #mode: // 16 = hop-on leg
set newindex + 4 #legindex; // another leg always follows
gosub NextLeg #togo #newindex #startsqr #to #locustsqr #dropsqr #len;
endif;
was added at the top of the section for occupied end-points. Another leg is guaranteed to follow here, so we don't even have to test for the value of togo. We do have to do that at the end of NextLeg, where we call NextLeg only if togo > 0 (in a similar way as above), and otherwise call GotMove. In this phase this recursive call serves only to handle the bent riders. The conditional section for occupied squares, which would use that recursive call for finishing locust captures, is temporarily disabled by putting a return statement where it will eventually set the locust square.
The more tricky part is enforcing the 'non-jumping' feature of XBetza. This is only well-defined on purely orthogonal or diagonal moves, and should never be used for obliques. The code works by first deriving the basic step in the same direction as the lame leap, and then uses that to generate the slide along the ray of the ride. This way it will also encounter any intermediate pieces over which the ride jumped. The number of steps is then converted to a number of leaps in the ride by multiplying with the ratio of the lengths. This can lead to shortening of the ride. As a length measure we use |dx| + |dy|, to make sure it is never zero.
if & 128 #mode: // 128 = non-jumping
set hx >> + 8 * 5 #dx 4; // derive unit step
set hy >> + 8 * 5 #dy 4; // (works for |dx|, |dy| = 0, 2, 3, 4).
set len count ride #starsqr #hx #hy; // distance to first obstacle along ray
set len * #len + abs #hx abs #hy; // |hx| + |hy| is measure of step length
set len / #len + abs #dx abs #dy; // distance in leg's leaps, rounded down
verify #len;
set r min #r #len; // clip blocked part of path
// TODO: e.p. rights creation
endif;
In this phase 4 the initial Pawn pushes are thus correctly generated. (In phase 3 they were still able to jump.) The Vao now has its capture move, and the Giraffe the intended Griffon move (instead of the Ferz that it was in phase 3). We are now in a position to implement the creation of e.p. rights due to such lame leaps that are used as initial Pawn moves.
I have advanced one more phase already. For one, I added some multi-leg capability to the move generator, namely the case where this is 'transparent' (i.e. without side effects). So the recursive calls to NextLeg are in place. This makes hoppers and bent riders work. Like their single-leg counterparts, such moves are also fully defined by the origin and destination square, and can be further processed in the same way. Therefore this was a quite trivial change. E.g. for handling the hoppers the code
if & 16 #mode: // 16 = hop-on leg set newindex + 4 #legindex; // another leg always follows gosub NextLeg #togo #newindex #startsqr #to #locustsqr #dropsqr #len; endif;was added at the top of the section for occupied end-points. Another leg is guaranteed to follow here, so we don't even have to test for the value of togo. We do have to do that at the end of NextLeg, where we call NextLeg only if togo > 0 (in a similar way as above), and otherwise call GotMove. In this phase this recursive call serves only to handle the bent riders. The conditional section for occupied squares, which would use that recursive call for finishing locust captures, is temporarily disabled by putting a return statement where it will eventually set the locust square.
The more tricky part is enforcing the 'non-jumping' feature of XBetza. This is only well-defined on purely orthogonal or diagonal moves, and should never be used for obliques. The code works by first deriving the basic step in the same direction as the lame leap, and then uses that to generate the slide along the ray of the ride. This way it will also encounter any intermediate pieces over which the ride jumped. The number of steps is then converted to a number of leaps in the ride by multiplying with the ratio of the lengths. This can lead to shortening of the ride. As a length measure we use |dx| + |dy|, to make sure it is never zero.
if & 128 #mode: // 128 = non-jumping set hx >> + 8 * 5 #dx 4; // derive unit step set hy >> + 8 * 5 #dy 4; // (works for |dx|, |dy| = 0, 2, 3, 4). set len count ride #starsqr #hx #hy; // distance to first obstacle along ray set len * #len + abs #hx abs #hy; // |hx| + |hy| is measure of step length set len / #len + abs #dx abs #dy; // distance in leg's leaps, rounded down verify #len; set r min #r #len; // clip blocked part of path // TODO: e.p. rights creation endif;In this phase 4 the initial Pawn pushes are thus correctly generated. (In phase 3 they were still able to jump.) The Vao now has its capture move, and the Giraffe the intended Griffon move (instead of the Ferz that it was in phase 3). We are now in a position to implement the creation of e.p. rights due to such lame leaps that are used as initial Pawn moves.