Comments by HGMuller

This article makes it easy to find how a piece of a given name moves. But the reverse is still very difficult. Perhaps there should be an index of some kind, where you can alphabetically look up the Betza notation, and find names that are used for a piece that moves that way.

Except that Betza notation is not really unique. So for this to work we should define some 'canonical form' of the notation, which would tell us that we would have to look for WD rather than DW. This makes purely alphabetic order perhaps less convenient; ordering primarily by atom, ignoring the modifiers and ranges might be preferable.

Anyway, these thoughts occurred to me when I was wondering whether there exist names for AH and DG, the 'expanded' versions of Kirin and Phoenix. I suppose these pieces qualify as amphibians, as the individual D, A, G and H components are severely area bound, while AH can go anywhere, and DG only has normal color binding.

This could be a mini version that is playable by (a future version of) Fairy Stockfish:

Camels and Zebras seem too have too long leaps even on 10x10, and would hardly benefit from their moves becoming rides. So I used AH and DG instead, where the D and A turn into rides on their own board half. Their permanent capture move is then too long range for being very useful in defense. (It would have to be so near the enemy that it can be easily chased away when used to protect squares in its own camp.)

It appears to be in the article under the name 'Newt'. A one-letter abbreviation would collide with that for Knight, though.

BTW, I used a standard Frog (FH) in Megalomachy; perhaps this can be added to the artice?

You posted this with the Checkmating Applet, where it doesn't belong. Please copy-paste it to a new posting in a place where it does belong, and then delete this one.

BTW, why do you always replace a single army in the existing CwDA Diagram? You obviously know what you have to change to make that work, and instead of changing it, you could just add it. And add one or more rows of buttons to select the new armies. Then the Diagram could also play the new armies against each other.

I would guess that the weakness of the pieces makes it very difficult to achieve checkmate, so that the game would focus on trying to reach the other side, and win by campmate.

The Chu-Shogi Lion's turn pass can be written as mabK or [K-bK]. But there is no way to enter a turn pass in the Interactive Diagram. Since the Diagram does not enforce turn order, though, you can pass a turn in any Diagram by simply playing two moves for the other side in a row. If you want the AI to play the extra move you can use the Move button. It messes up the game notation, though. Perhaps I should let the notation code detect this, and insert a null move (e.g. --).

I can add that even though the rules in Chu Shogi do allow you to pass a turn in some situations, I so far could not imagine any position where this would be a good move.

If you are talking about bitmaps of piece that were rendered from some higher resolution (or vector image) using anti-aliasing on a white background, the pieces all having black outlines, then indeed, replacing the grey with black, and using the bitwise complement of the grey-scale value as alpha channel would mix in as much background as the original image would have mixed in white. Additional condition is that the image would not contain any internal grey pixels. This could be problematic with pieces that had purely white filling; the algorithm would treat the white filling the same as the exterior, and make the entire piece transparent.

This could be avoided by using a flood-fill-like algorithm, which only treats pixels which neighbored other pixels that were changed. And then start in a corner pixel.

Old bitmap images might not have anti-aliasing, though. These would just have a ragged boundary  between an absolutely black outline and a uniform background of another color. (The original Alfaeries are like that.)

But FSF of course is likely to play it very poorly. So it is not clear whether any conclusion can be drawn from that.

I suppose the heuristic used by the Interactive Diagram implicitly does something similar. Most of the piece value is determined by the number of captures the piece on average can make. But this is measured on a 25% filled board,  where the density of pieces of a certain color decreases linearly from their own backrank to zero just beyond the furthrest rank. The larger number of enemy pieces it will hit in the forward direction will then cause more captures for the forward moves than for similar backward moves.

I also used it, in Team-Mate Chess, where I called it Unicorn. Because this was one of the Knight-like piece images available in WinBoard.

The a does not stand for 'after' but for 'and again', which is the same as 'before'. So afsW means W before fsW: first a W step in any of the 4 directions, and then another step at 45 degrees (fs) relative orientation to it.

Values are guestimated through a rather complex method, based on the empirical observation (i.e. from playing thousands of computer games starting from materially imbalanced positions) that short-range leapers with N moves have a value (33 + 0.7*N)*N centi-Pawn, where captures contribute twice as much as non-captures. To extend that to other classes of pieces their number of moves is calculated in a number of randomly generated positions with 25% filled boards, where the density of a certain color decreases to 0 at the furthest rank. And the average of this plus one standard deviation is then taken to plug into the formula for leapers.

You lost me. What is this 'font size' you are referring to? Is this because you have the orthodox set as font (TTF), and try to produce other images as individual .svg files?

Font sizes are typically referred to in 'point' units, which is not the same as pixels. I don't know how the various point sizes correspont to pixels; this must be glyph-dependent, at least for the width in proportional fonts.

SVG images have an intrinsic size, but it is often ignored by the software rendering it. I think the Alfaerie SVGs are 2048x2048, but including them as image on a HTML page without size instructions renders them as 150x150. That is a browser decision.

In making the Magnetic and Motif SVGs I started from individual SVG images from the GitHub pychess repository, not from the font.

OK. I don't know why you changed the size, but when the set is finished we could include them in a new directory magneticL.