Single Comment

I am having some second thoughts about this old patch of the animation routine. This was in base-view.js, btw, so only affecting chess variants. But this code is also used by hexagonal variants, or variants with irregular board topologies. There the way I use to detect oblique slides, and break them up into on-ray legs, would not work at all, and probably break things. The original default cbMoveMidZ at this level would always slide. Only when you use a grid board this would be overruled by one that jumps for all obliques, and slides otherwise (and which I now replaced by a more advanced one).

So this animation patch in its current form is probably not acceptable for Jocly in general. The animation routine consults cbMoveMidZ to calculate the trajectory along which it will move the piece during animation. So a solution would be to only break up the trajectory into two legs when cbMoveMidZ requests this, as each board topology would have its own cbMoveMidZ. So the latter would then not only be used to define the Z coordinate half-way, but also the (x,y) coordinates.

Since the (x,y) path of a move that hops over other pieces is irrelevant (and thus can be the normal straight line it is now), we could use negative value of the number returned by cbMoveMidZ to specify the intermediate for a slide. (I cannot imagine you would really need jumps with negative height...) E.g. minus the number of the square over which the slide should go, minus 1. Then a jump height of 0 would indicate a normal slide, as the original use of cbMoveMidZ intended. The default cbMoveMidZ for the grid board would then recognize oblique slides, and determoine the intermediate square itself. I guess for the moment it would be good enough to just take the first square on the path as the intermediate. That would work for Griffon, Rhino and Osprey.

It would even work somewhat for the Grant Acedrex Unicorno (which would squeeze itself between the pieces shielding it from its first target). It might even be nicer if in that case (i.e. a path starting on a non-adjacent square) would be animated as a jump in the first leg, followed by a slide. That would also be good for the Osprey. The animation routine would then have to determine a default height for that, though, as the value returned by cbMoveMidZ would indicate the horizontal intermediate. Perhaps we should make it possible for cbMoveMidZ to return an array, with both a height and an intermediate.