Single Comment

I tried to use fr-terror in Makromachy and Minjiku Shogi, but it doesn't show up, and the JavaScript console of the browser reports an error (in a piece of code that looks totally unfamiliar to me, so presumably in the rendering library). So there seems to be something wrong in the .js file. (It seems to contain a lot of cruft, besides the lists of coordinates.)

Some other thoughts:

Visuals: When I look at the 2d visual you made for Mirza, the Griffon symbol strikes me as way too big compared to the symbols for the orthodox pieces. In fact the latter strike me as way too small for the square size that is used, and located too high in the square (which might be a consequence of that). To a lesser extent that also applies to the Prince symbol. (I suppose it doesn't stick out that much because it depicts a naturally smaller object.)

The black Cannon2 seems to have a black line above it in your visual that doesn't belong there. In the 2D representation of Makromachy I don't see that, though. The squares are smaller there, and this emphasizes that the white Cannon2 is really drawn too low.

I guess we should make an effort to harmonize the fairy-sprites.

PiecesFromFEN: For variants with complex promotion rules it is still a pain to extract the piece-type numbers for use in the promote routine. Would it make sense to make these numbers more predictable for the programmer? We could adopt the convention that P and S come first (in that order), and take the numbers 0-1 (or 0-3 if both are present, which would be extremely rare). After that all non-King pieces in alphabetical order of their ID in the FEN, and King last. This would be just a matter of re-ordering the tests for the presence of the pieces in cbPiecesFromFEN. In Grand Chess they would then know that A=2, B=3, M=4, N=5, Q=6 and R=7.

The assumed piece values are what they should be for an 8x8 board. For larger variants people might want different values (upgrading sliders as compared to leapers), and it currently would be a pain to redefine all values through statements like "p.pieceTypes[name2nr['rook]].value=...". If people want to redefine values, it is likely they want to redefine it for all the pieces. So perhaps there should be a function for that, which takes an object with the new values as argument. Like

p.setValues({P:0.8, N:2.5, B:3.75, R:6, Q:11});

Of course that might be futile, as people implementing the variant might have no idea what the piece values are, and actually make things worse than just using the default 8x8 values. So perhaps the default values should take account of the board size, to reduce the need for hand tuning.

Tube: The pieces we can generate now are acceptable, but I still think their diffusemaps should be better. They seem a bit bland to me. E.g. if I look at Saint or Caliph, their down-pointing surfaces are not nearly as dark as the head of the King & Queen. The natural shading algorithm gets some assistance there from a darkness gradient in the diffusemap for the head sections. I think we should have that too. It might be hard to do it automatically, but we could provide a command to order it in the tube input file. Like allowing mention of a second color in paint/shade, which would then then be interpolated to start at the first and end at the second as we traverse through the ring. And then redo all pieces we made so far, to replace their diffusemaps.