When trying to play a variant chess game, XBoard will display kings in
place of the appropriate variant pieces.  For example,

$xboard -ncp -variant gothic

Instead of displaying chancellors on e1 and e8, and archbishops on g1
and g8, XBoard displays kings on all four squares.  The chancellors
and archbishops do move as they are supposed to.

$xboard -ncp -variant xiangqi

XBoard shows Xiangqi implemented using a chess board and chess pieces,
which is workable except that the king is used to represent three
different pieces - generals, guards, and elephants.

$xboard -ncp -variant shogi

Same problem as with Xingqi:  a chess board instead of a Shogi board and
a chess king is used to represent Shogi kings, gold generals, silver
generals, and lances.

Note also that XBoard screenshots on the XBoard homepage show Xinqgi and
Shogi games with the correct boards and pieces.

This should be considered a short-coming of the documentation:

XBoard 4.4.0 has built-in bitmaps for all non-orthodox piece types only
in -boardSize middling and bulky, and almost all in petite. The Archbishop
and Chancellor have built-in bitmaps in any size from petite to bulky.
The other boardSizes can of course still be used with these variants
when people provide their own bitmaps / pixmaps. The reason we felt that
providing built-ins for only 3 sizes would be enough is that there really are
no standard representatons for un-orthodox pieces, so people are much
more likely to want to provide their own bitmaps. E.g. people playing
xiangqi are likely to prefer pieces that look like Chinese characters.
Providing built-ins for 2 x 22 piece types at 18 sizes would lead to
unjustifiable bloating of XBoard.

The XBoard manual fails to mention this, although it is mentioned in the
manual page of the engine playing these variants. This obviously should
be corrected.

It might be more user-friendly to actually put a conspicuous warning
message about this in the File -> New Variant dialog. That still leaves
people that start through the -variant command-line option in the cold.
But commands like

xboard -variant shogi -boardSize middling
xboard -variant xianggi -boardSize bulky

would not suffer from the reported limitation, and if this is conspicuously
stated in the manual in the place where these variants are mentioned,
that should provide people with enough warning.

I will see to it that this is done before the final release of 4.4.0.

H.G.Muller,
upstream XBoard developer

Your notes clear up the king problem, but in looking at board sizes for
the Capablanca and gothic variants I found some interesting things.

The archbishop pixmaps do run the range from petite to bulky.  For
petite, middling, and bulky the pixmap is a pair of crossed swords.
But for the rest it's a mitre (a fat mitre in contrast to the bishop's
thin mitre).  The gothic chess website uses the fat mitre, but the
Wikipedia articles on both Capablanca and gothic use a knight's
horsehead placed on a bishop's base.

The pixmaps as45o.bm and as45s.bm are also crossed swords.  There are no
as* pixmaps in other sizes.  Pixmaps a45o.bm and a45s.bm are fat mitres.

The gothic variant uses the d*.bm pixmaps for the chancellor - a
knight's horsehead placed on an inverted rook's top.  However, the
Capablanca variant uses the six-pointed star from the c*.bm pixmaps.
The gothic chess website and the Wikipedia articles on Capablanca and
gothic use the knight/rook combination for the chancellor.

In light of this I suggest the following fixes:

1)  For the Capablanca variant use the d*.bm pixmaps instead of the
c*.bm pixmaps for the chancellor piece.

2)  For the archbishop pixmaps replace a33*.bm, a49*.bm, and a72*bm with
pixmaps of fat mitres.  There's no reason to throw them out, so rename
the old crossed sword pixmaps as as*.bm.

3)  Add a new set of archbishop pixmaps to match the knight/bishop
combination.

I would think 1) should be easy to implement before the next XBoard
release, and maybe 2) since only three new pixmaps are needed to fill
out the range of sizes for the archbishop piece.  3) would be nice to
have, but can go on the wish list.

Well, as I said, there exist no standards for this. People even quarrel about
the names of these pieces; the Archbishop is also known as Cardinal, and
the Chancellor is known as Marshall. The crossed sword symbol is used
by Reinhard Scharnagel's SMIRF engine, and many Capablanca players
are emotionally attached to it. OTOH Gothic-Chess fans like to have
everything exactly their way.

Personally I abhor "cut and paste" piece symbols; we don't symbolize
a Queen by a Bishop on top of a Rook.

So the solution I have chosen was meant as a compromise. By using
flattened mitre in some sizes and crossed swords in the other for A
people can just pick a slightly different size if they strongly prefer one
representation over the other. The representation of the chancellor is
decided by selecting the variant (Gothic vs Capablanca). These variants
only differ in initial setup, so if people really care about the C
representation
they can play Capablanca as Gothic by starting from a setup position
(in the -loadPositionFile).

What you say is very easy to do, but it would anger about half the
10x8 community. Although the chosen compromise seems a bit
illogical, I think it actually provides more flexibility, and will contribute
to the success of XBoard as a standard interface in the 10x8 community.

H.G. Muller

h.g. muller wrote:

You could build on the compromise by creating pixmaps for the missing
sizes and keeping the mitres and swords in separate sets - all mitres in
a*.bm and all swords in as*.bm.  The Gothic and Capablanca archbishops
default to their appropriate representations with all sizes available to
the user.  Just as you've done with the chancellor...

And with complete sets available, players could do the same with the
archbishop.  No one will see kings where they should see the archbishops
and chancellors of their chosen variant.  At least for the Capablanca
and Gothic players.  The players of other variants can submit their own
bug reports. :)

Updating the documentation will be enough for me to consider this bug
closed.  My suggestions above can go on the XBoard wish list.

Thanks.