Grande Acedrex

[hgm]

OK, apparently the Zebra did not make it into git.

I must admit I also get the error popup about missing default pieces, but it then doesn't segfault, and runs normally. IIRC this started after I added the Lion duplicate and a promoted counterpart, and I did not pay much attention to it, as I assumed it was just a typo in the name of that promoted counterpart. I will check it out.

[hgm]

I pushed new commits, which add the white Zebra to git, and hopefully fix the segfault. Turned out I had forgotten to put an extra NULL element in the list of 'backup' pieces (responsible for loading a King image when there is no Prince SVG) when I added the 'minor Lion', so that the pieces behind it (the promoted series) had gotten out of phase, (causing the promoted Kirin, which is not in the default set, not having a backup) and was accessed out of bounds for the last piece (which could explain the segfault).

[Evert]

I pushed new commits, which add the white Zebra to git, and hopefully fix the segfault. Turned out I had forgotten to put an extra NULL element in the list of 'backup' pieces (responsible for loading a King image when there is no Prince SVG) when I added the 'minor Lion', so that the pieces behind it (the promoted series) had gotten out of phase, (causing the promoted Kirin, which is not in the default set, not having a backup) and was accessed out of bounds for the last piece (which could explain the segfault).

It fixes the segfault, but the "no default pieces" message is still there:

Code: Select all

No default pieces installed!
Select your own using '-pieceImageDirectory'. (Cub)

Also, the board window appears to be messed up (see to the right of the board; the bottom is clipped):

If I make the window taller the problem disappears. Any thoughts?[/img]

[hgm]

Apparently I forgot to mention the most-recently added pieces (Cub and Dragon) in the Makefile as svg_DATA, so that although they are now in git, and thus in the snapshot tar ball, they were not copied to XBoard's default piece directory during install. I fixed this about an hour ago, but I had not pushed to nubati yet.

The clipping problem at the bottom is weird. Normally XBoard adapts the drawing to the size of the window. We have had similar effects in the past, and they were traceable to the size change of the clock widgets on instating the clock font. But these were persistent. The fact that it now disappears when you resize the window suggests that it somehow misses the event that is supposed to do that automatically, possibly because of a timing problem.

That there is unused space on the right is to be expected if the window cannot be made high enough. The menu bar and clocks force a minimum width on the window. The clocks can be mande narrower by passing a smaller -size argument to XBoard, and at some point this also starts to shrink the menu bar by clipping the texts of the individual menu items. If your GTK uses a larger font for menu bars than what I assumed, the texts would not be clipped enough, and the menu bar would remain too wide and dominate the width of the window.

[Evert]

The version of Fairy-Max currently in your repository seems to hang if it is told to use more than 1024 MB:

Code: Select all

$ fairymax 
tellics say     Fairy-Max 4.8V
tellics say     by H.G. Muller
memory 1024
ping 1
pong 1
memory 2048
ping 2
<no reply>

[Evert]

By the way, first "proper" game:

Code: Select all

[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2016.01.12"]
[Round "1"]
[White "Postduif 0.11"]
[Black "Fairy-Max 4.8V"]
[Result "1-0"]
[TimeControl "40/10"]
[Variant "grande-acedrex"]
[VariantMen "P:fmWfcF;C:B;R:R;A:FyafsF;U:NmpafsyafW;G:Z;L:HC;K:KimDimA"]
[FEN "rlugcakcgulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUGCAKCGULR w Kk - 0 1"]
[SetUp "1"]

{--------------
r l u g c a k c g u l r
. . . . . . . . . . . .
. . . . . . . . . . . .
p p p p p p p p p p p p
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
P P P P P P P P P P P P
. . . . . . . . . . . .
. . . . . . . . . . . .
R L U G C A K C G U L R
white to play
--------------}
1. Ui3 {+0.22/7} Ue11 {+0.21/5 0.5} 2. Gl3 {+0.75/6 0.2} h8 {-0.06/4 0.1}
3. Ug6 {+0.36/6 0.4} Ck6 {+0.23/4 0.1} 4. j5 {-0.66/6 0.3} Ci8
{+0.43/5 0.3} 5. Ue5 {-0.88/5 0.2} Gg10 {-0.02/4 0.4} 6. Gj6 {+0.15/5 0.1}
Gf10 {-0.06/4 0.5} 7. Ub3 {+0.46/5 2.0} Gh7 {+0.06/4 0.1} 8. Ud7
{+0.46/3 0.1} Cf10 {-0.01/4 0.3} 9. Ud6 {-0.32/4 0.4} e8 {+0.22/3 0.1} 10.
Ug5 {-1.27/2 0.1} Cd8 {+0.25/4 0.3} 11. Gh9 {-1.58/3 0.4} Cxg5
{-0.42/5 0.3} 12. Gxf12 {-0.68/3 0.2} Gxf4 {-0.73/4 0.4} 13. Uj11
{+0.96/4 0.2} Uk10 {-0.88/3 0.1} 14. hxg5 {+0.81/4 0.3} Gxh1 {-1.12/4 0.1}
15. Ck7 {+2.07/4 0.2} Lh12 {-1.31/3 0.2} 16. Lxh1 {+2.65/3 0.1} k8
{-1.58/5 0.5} 17. Gi10 {+5.51/4 0.1} Rj12 {-1.40/5 0.1} 18. Uk9
{+2.78/5 0.2} Uxg5 {-1.08/4 0.1} 19. Gl8+ {+1.76/4 0.2} Ke10 {+0.27/3 0.1}
20. Ui10 {-0.88/4 0.1} Uxe4+ {+1.37/5 0.3} 21. Axe4 {-1.16/4 0.1} Cxe4
{+1.67/5 0.1} 22. Lh4 {-0.13/6 0.2} Cxb1 {+1.89/5 0.3} 23. Rxb1
{-0.10/7 0.2} j8 {+2.11/5 0.4} 24. Ci5 {+0.58/6 0.2} f8 {+2.07/5 0.2} 25.
Uf12+ {-0.45/5 0.3} Kf11 {+2.27/5 0.1} 26. Gi10 {-2.57/6 0.2} Gi7
{+2.61/5 0.4} 27. Le5 {-1.70/4 0.2} Gxg4 {+3.12/4 1.1} 28. Cxf8
{-1.66/6 0.3} Lk11 {+2.44/3 0.1} 29. Ud11 {-0.51/6 0.1} gxf8 {+1.04/4 0.1}
30. Ue9+ {-1.28/7 0.2} Kf10 {+0.57/4 0.1} 31. Uxa12 {-1.28/7 0.2} f7
{+0.07/4 0.1} 32. Gf4 {-0.22/6 0.1} Rg12 {+0.74/4 0.1} 33. Lf8
{+0.58/7 0.3} Gi7+ {+0.75/4 0.1} 34. Kf1 {+0.00/6 0.2} Ug8 {+0.01/5 0.6}
35. Kf2 {+0.93/6 0.1} Ri12 {+0.52/3 0.1} 36. Rlg1 {+4.92/6 0.1} Le11
{-0.96/4 0.1} 37. Gh7+ {+6.57/6 0.1} Ke10 {-5.51/4 0.1} 38. Uxc9+
{+11.70/7 0.3} Kf9 {-5.75/4 0.1} 39. Li8+ {+9.02/6 0.1} Kg9 {-5.76/5 0.3}
40. Ue10+ {+11.68/6 0.1} Kh10 {-5.28/5 0.2} 41. Rxg8 {+9.22/7 0.3} Rxi10
{-5.09/5 0.4} 42. Gk9 {+10.35/6 0.2} Rk10 {-5.04/4 0.1} 43. Gi12
{+8.20/6 0.3} Lkh11 {-4.86/5 0.4} 44. Ud12 {+9.83/6 0.3} Rk12 {-5.42/5 0.9}
45. Rg12 {+11.75/6 0.3} b8 {-5.39/4 0.1} 46. Uf11+ {+14.43/6 0.3} Ki10
{-5.89/4 0.2} 47. Ll8 {+13.82/5 0.2} Gxk4 {-6.03/5 0.2} 48. Lxi9
{+15.82/7 0.3} Gi7 {-6.01/5 0.2} 49. j6 {+16.40/6 0.3} Rl12 {-6.43/4 0.1}
50. jxi7 {+18.20/6 0.4} jxi7 {-7.46/5 0.1} 51. Lf10+ {+18.76/7 0.2} Kj10
{-7.70/5 0.1} 52. Rj1+ {+19.51/7 0.3} Kk11 {-7.56/5 0.1} 53. Rj9
{+18.58/7 0.2} Lf8 {-7.80/5 0.3} 54. Rk9+ {+21.82/5 0.1} Lk10
{-14.62/6 0.1} 55. Uxh8 {+26.80/6 0.2} Rl10 {-17.43/6 0.2} 56. Uj9+
{+31.81/6 0.2} Kj11 {-79.96/6 0.1} 57. Uxl10+ {+39.73/7 0.2} Kk11
{-79.95/6 0.1} 58. Uh7+ {+41.12/8 0.4} Li9 {-79.96/7 0.2} 59. Uxi9
{+319.93/7 0.2} Kl12 {-79.98/14 0.1} 60. Ug8+ {+319.95/12 0.2} Kl11
{-79.98/28 0.1} 61. Li11+ {+319.97/64 0.1} Kk12 {-79.99/28 0.1} 62. Gg9#
{+319.99/64 0.1}
{Xboard adjudication: Checkmate} 1-0

Search depth is abysmal in both engines, and I'm sure the evaluation is equally horrible.

EDIT: I've seen some test games (against what amounts to a random-mover) that had evaluation scores go up to 100+ based on material...

[hgm]

The version of Fairy-Max currently in your repository seems to hang if it is told to use more than 1024 MB:

I guess this is to be expected for 32-bit programs; malloc() fails when you ask for 1GB or more.

I pushed a commit that caps the hash size to 384MB. It was halving the number of entries until the implied size was smaller than the memory parameter, and I just had to start at a smaller value.

I found another source for Mexican Chess, and it seems Pawns do have an initial triple-push there. It didn't say what the rules for e.p. capture are on a triple-push. Fairy-Max can do the triple push, but it will only allow e.p. capture on the last square the push skipped. So that is what I currently use. The XBoard Betza generator will allow e.p. capture also on the 1st square skipped in a triple push, when you specify 'e' mode. Perhaps I can still fix this, by ignoring certain bits through a square-dependent mask when comparing if a move goes to the e.p. square.

I also had a look at Wildebeest Chess (11x10). It features a Gnu, and for a GNU project that seems a must! Unfortunately it has complex rules, which Fairy-Max cannot fully handle: initial triple push with e.p. on both squares, in addition to a double push (so far so good), but also a double-push from 3rd rank (argh!). And for castling the King can move 1, 2, 3 or 4 squares towards the Rook. Fairy-Max can do 2 and 3, but not 4 without missing some castlings through check. And to move 1 square seems to raise protocol issues.

[Evert]

The version of Fairy-Max currently in your repository seems to hang if it is told to use more than 1024 MB:

I guess this is to be expected for 32-bit programs; malloc() fails when you ask for 1GB or more.

Maybe, but it compiled to a 64 bit binary here.

I also had a look at Wildebeest Chess (11x10). It features a Gnu, and for a GNU project that seems a must! Unfortunately it has complex rules, which Fairy-Max cannot fully handle: initial triple push with e.p. on both squares, in addition to a double push (so far so good), but also a double-push from 3rd rank (argh!). And for castling the King can move 1, 2, 3 or 4 squares towards the Rook. Fairy-Max can do 2 and 3, but not 4 without missing some castlings through check. And to move 1 square seems to raise protocol issues.

The en-passant rules I can handle with SjaakII. The double push from the third rank is problematic. I can do castling where the king moves 1 or 4 squares (or anything in between) but not at the user's option... although I probably could make that work with some effort.

[hgm]

Maybe, but it compiled to a 64 bit binary here.

That is indeed strange. It used to start with a 'mask' 2^31-1, and kept cutting it in half until it was lower than 1024*1024*memory/12. For memory=1024 this should not yet overflow a 32-bit signed int, so I would expect it to stop at a mask value of 16M, which translates to a calloc() of 768MB. Not something you would expect to fail ona 64-bit architecture.

A more tricky issue is that when memory >= 2048 the conversion of the memory parameter to the maximum number of entries would overflow. So even the current method is not fool proof.

The en-passant rules I can handle with SjaakII. The double push from the third rank is problematic. I can do castling where the king moves 1 or 4 squares (or anything in between) but not at the user's option... although I probably could make that work with some effort.

We would have to decide how to encode a 1-step castling. Both the O-O notation and the KxR notation suffer from that they don't contain any direct information on the to-squares of King and Rook. Those must follow from the rules, and currently XBoard assumes these rules would be Fischer castling. We could adopt the convention that in variants that do not have Fischer castling O-O would mean the King step n indicated by the On atom with the smallest n. This means isO1 could be used to define a 1-step castling indicated as O-O (h-side) or O-O-O (a-side). The more-step castlings could be indicated by the King step, at least when the piece moves as orthodox King.

I wonder if I should allow the notation isO0 in piece commands to indicate 'sliding castling' with arbitrary range, so that you would not have to specify all possible King steps separately (as separate O atoms). I guess the occurrence of this would be so rare that I should not worry about it.

[Evert]

That first game was apparently a fluke, since FairyMax has one every single game since...