Few small bugs on version 4.4.3

[Nguyen Pham]

Hi all,
Just few bugs when I play with WB:

- Command line with parameter /debug true (as the document) will make an error box "Can't open "true" The system cannot find the file specified" and other box Fatal Error "Bad game file". If I change to /debug only, it works fine
- If I run a Xiangqi engine and resize the board to the smallest size, some pieces will be changed to Western chess pieces, some others will disappear. The grid/lines of board are also very hard (not clear) to see.

Regards,
Pham

[matematiko]

I am not an expert but: debug is off by default, to turn it on all you have to do is add /debug not /debug true.

Also by default, the log is going to be written in a file called WinBoard.debug. There is an option to change the debug file name, and it looks to me your command /debug true is trying to create a file called "true"

This explains why it works fine with /debug but fails with /debug true
I do not know anything about the other problem sorry.

Good luck,

[H.G.Muller]

Thanks for reporting! Indeed /debug is supposed to be an option without arguments, as Matematiko states. So this should count as an error in the documentation. I will look into it. The other error popup then likely is a consequence of the option parsing getting out of phase. What exactly was the command line you were using to start WinBoard?

Font-base rendering of pieces (which is used to get the oriental-style Xiangqi board) seems to be intentionally switched off below a certain size. I am not sure what could be the reason for that. I will try to remove that test, and see if there are any adverse effects. In the particular case of the XIANGQI font, my guess is that the pieces need a quite high resolution to remain recognizable, more so than a simple western-style Chess font. But this cannot have been the reason, as the font-based rendering was implemented by Alessandro at a time WinBoard did not support any non-FIDE pieces yet.

About the board lines? I will have a look. The board squares are simply cut from a bit map, and not magnified or demagnified. SO in theory the lines should retain their width. The position from which they are cut might not be calculated properly, though.

[Mathieu]

Font-base rendering of pieces (which is used to get the oriental-style Xiangqi board) seems to be intentionally switched off below a certain size. I am not sure what could be the reason for that.

Maybe because common fonts (such as merida etc easily found on the web) becomes "transparent" if too small, at least it was the case in older builds (i don't use it anymore). Modified fonts (thicker lines) was a work around.

[Nguyen Pham]

Hi,

If you use a bitmap for displaying board lines, that is a problem for resizing. Bitmap is not good if we resize too much: When magnifying, it will look ugly and dim, when demagnifying, some lines will be missing. Usually I have to use few bitmaps with different sizes and use each of them in a specific range. Other solution is to draw lines, using GUI library.

I have checked the font Xiangq and see that it has the smallest size of 6pt (very small) and in my MS Word it can display well all pieces which look smaller than pieces displaying in WB. Perhaps it is rendering algorithms problem? BTW what is the purpose of parameter /fontPieceSize? I have tried to change it from 70 to 6 but did not see any effect.

I have seen another problem of chasing / perpetual checking. That happens in one game (but because of testing configuration I did not save the game). I have to wait WB for long time (the repeat must be larger than 3) to see if it would stop the game and announce the result but it seems be not. I am not sure if it is my mistake of setting command line (at that moment I have not got parameter /repeatsToDraw=3 )?

Regards,

PS:
My bat file to run program looks like that:

start /wait C:\WinBoard\WinBoard\winboard /debug /repeatsToDraw=3 /sgf c:\saocon\tourgames.png /autosave /variant=xiangqi -cp -fcp "saola" -fd "C:\saocon1" -scp "saola" -sd "C:\saocon2" -initString "new\n" /mg 10 /tc 2 /mps 40 /inc -1 /liteBackTextureFile="textures/xqwood.bmp" /darkBackTextureFile="textures/xqwood.bmp" /liteBackTextureMode=1 /darkBackTextureMode=1 /overrideLineGap=0 /highlightMoveWithArrow=true /renderPiecesWithFont="XIANGQI" /fontPieceToCharTable="ph.r.ae..k.cxPH.R.AE..K.CX" /fontPieceBackColorWhite=#ffffff /fontPieceForeColorWhite=#ff1010 /fontPieceBackColorBlack=#ffffff /fontPieceForeColorBlack=#8080ff /fontPieceSize=70

[H.G.Muller]

The algorithm that creates a bitmap from the font needs to distinguish inside of a piece from outside, because it has to color the inside, and make the outside transparent. It uses flood-fill from the corners of the square to make that distinction. The risk exists that rendering pieces at very small size will create 'leaky borders', so the flood-fill will get to the inside, and the piece will become transparent. I am not sure the XIANGQI font is very sensitive to this. If this is a problem is very much dependent on your hardware; it seems the flood-fill is ultimately done in the video-card driver. Anyway, it seems unwise to swicth of the font-based rendering below a certain size in anything but standard Chess, as there will be no built-in bitmaps for some of the pieces either. So it will only replace a cosmetic problem by a much more serious problem of not seeing all pieces. So I guess the best solution will be to make the disabling variant-dependent.

The /fontPiceSize is supposed to tune the size of the pieces as a percentage of the square size. There might be a restriction on its value, so the 6 is not accepted. It is used as a factor to calculate the point size passed to the drawing routine for rendering the font symbols in a bitmap drawing. I remember that using 70, 80 or 90 did create a visible difference. I will check it out.

The board bitmap is not re-sized. The 'texture' bitmap given is used to cut squares from it. If the given bitmap has exactly the size of a square, all squares would be identical. If it is larger, the various squares are cut out offset from each other. E.g. if the board is 8 squares wide, the square 10 pixels wide, and the texture bitmap 45 pixels wide, the squares would be cut as 0-9, 5-14, ..., 35-44, i.e. they would overlap 5 pixels. If the bitmap is larger than all squares together, they would be cut out with some left-over space between them, but in such a way that the squares on the edge all touch the edge of the bitmap. I guess the latter is a bad idea; I should cut them in such a way that they leave an unused area of half the size of the spacing between the squares, so the grid points of the grid drawn in the bitmap stay in the center of the squares. As the outer edge line of the Xiangqi grid is half a square away from the edge of the board bitmap, cutting out too small a square that is touching the edge will miss the grid line altogether.

The command-line looks OK to me. Note that most of the parameters you specify would be remembered in the settings file when you would save the settings. (But the way WB 4.4.3 is configured in the installer package is with save-settings-on-exit off, so you would have to do it by hand.) You must make sure legality testing is on, but it should be by default.
With /repeatsToDraw=3 the game should be adjudicated on the third occurrence of the same position, unless it would be a win for the side that just moved. In that case the adjudication is deferred one move. (I am not sure if this is proper procedure, but it was how XQWLight treated perpetual checking, and it seemed to make sense to give the checking side a chance to alter his moves after the evading side proved he could cause a repeat.)

It could be you are running into a bug of WB 4.4.3 here: when the evading side was the first to exceed the number of allowed repetitions, it had already stopped the engines by sending them a force command before I decided to defer the call by one move. So then the engine that was in violation would lose on time. If you were using 4.4.3, please replace the binary by the one at this link:

http://hgm.nubati.net/winboard0526.zip

You could set /repeatsToDraw to 2 to have WB adjudicate earlier.

[H.G.Muller]

OK, I think I fixed the probems with small board sizes now, and put the fixed version at the link given above. If the total board size is larger than the bitmap of the Xiangqi board there is still little I can do. Centering the cut-out squares on the grid points would then have them spill over the edge of the given bitmap, leading to a black rim around the board. Better would be to cut squares from the bitmap such that their centers are on a regular grid that leaves 129/2 room to the edge. (129 is the largest supported square size.) The bitmap of the board would then also have to be drawn that way.

An alternative could of course be to simply provide a larger bitmap. I guess for the really large board sizes, one would like to have thicker grid lines anyway.

[Josh Pettus]

If you want a larger XQ board there is always this marble one that I did last year when I was playing around with it. I made it for board size "Bulky" as I have a 1440x900 native resolution monitor. Doesn't look so good resizing downward though because of the marble texture. I should make one with a more tile-able background texture next time. Also the diagonal's were never perfect but close enough.

[Nguyen Pham]

Thank Muller,

The small board seems work very well. I love to observe my engine fighting on a corner of screen when working (my boss may sack me if he know what I am doing)

/Pham

[Josh Pettus]

well in that case A smaller board would be advantageous.

H.G.M, I tried resizing one of your boards to 639x710, and, thanks to your new board cutting technique, all boardsizes from Tiny to Bulky look pretty darn good. Don't know if anyone needs anything any larger.

[Nguyen Pham]

Hi Muller,

I have seen a game as the bellow. The last position is not a repeat and it is a Rook and two Elephants vs a Rook. Just wonder why WB thinks it is a draw?

[Event "Computer Chess Game"]
[Date "2010.07.01"]
[Round "8"]
[White "Saola"]
[Black "Saola"]
[Result "1/2-1/2"]
[TimeControl "40/120"]
[Variant "xiangqi"]
[Annotator "1. -0.03 1... -0.93"]

1. Hc2 {-0.03/10 2.0} Hc7 {-0.93/10 2.0} 2. Hg2 {-0.03/10 2.0} Hg7
{-0.66/10 2.0} 3. c4 {-1.34/10 2.0} g5 {-2.12/10 2.0} 4. Ch6 {-1.39/10 3}
Ece7 {-1.99/10 3} 5. Cg6 {+0.33/9 3} Rh9 {-2.04/10 3} 6. Ece2 {+0.06/9 3}
Ci7 {-1.48/10 3} 7. Cb6 {-0.94/10 3} Ade8 {+1.00/10 3} 8. Ade1 {-2.79/11 3}
Rd9 {-0.90/11 3} 9. Rd0 {-2.61/11 3} Rxd0+ {-1.38/10 3} 10. Kxd0
{-1.05/10 3} e5 {+0.64/10 3} 11. Ri1 {-2.50/10 3} Rh2 {+0.65/9 3} 12. Ri2
{-2.60/11 3} Rh3 {-1.40/10 3} 13. Hd4 {-0.86/10 3} Ca7 {+0.01/10 3} 14.
Hxc6 {-0.36/10 3} Cxa3 {-1.64/10 3} 15. Cb7 {-1.83/10 3} Cc3 {+0.03/9 3}
16. Hxe5 {-0.58/10 3} Ch7 {-1.36/9 3} 17. Cxg9+ {+0.59/10 0.5} Exg9 18.
Cxg7 {-1.86/13 3} Cxg3 {-2.14/12 3} 19. Cg6 {-2.12/12 3} Cxg6 {+0.25/11 3}
20. Hxg6 {-2.25/12 3} Cg7 {-1.43/12 3} 21. e4 {-2.21/12 3} Rg3 {+0.29/11 3}
22. e5 {+0.03/12 3} Hd9 {-0.03/11 3} 23. Ke0 {-1.98/13 3} He7 {-1.82/13 3}
24. Hxe7 {-2.22/14 3} Exe7 {-2.07/14 3} 25. Hi1 {-1.93/13 3} Re3
{-0.16/12 3} 26. ef5 {+0.02/12 3} Rf3 {-0.15/11 3} 27. fe5 {+0.07/12 3} Rb3
{-0.19/11 3} 28. e6 {-1.22/12 3} Eg9 {-2.78/11 3} 29. Rh2 {-1.07/12 3} Kd9
{-1.27/11 3} 30. Ad0 {-0.42/12 3} g4 {-1.59/11 3} 31. Rh3 {+1.13/11 3} g3
{-0.75/12 3} 32. Rh5 {+0.72/11 3} Rf3 {-2.39/12 3} 33. Rg5 {-1.25/12 3} Cb7
{-2.62/12 3} 34. Ade1 {+0.15/10 3} Cb1 {-1.99/12 3} 35. Rd5+ {-1.99/12 3}
Ke9 {-1.97/14 3} 36. Rd1 {-2.03/13 3} Cb7 {+0.02/12 3} 37. c5 {-2.02/12 3}
Rf1 {-0.21/12 3} 38. Rd3 {-1.86/13 3} Rg1 {-2.14/12 3} 39. c6 {-1.61/13 3}
a5 {-0.62/12 3} 40. Hh3 {+0.41/12 3} gxh3 {-2.43/13 3} 41. Rxh3
{-1.48/12 3} Rg5 {-2.17/12 3} 42. cd6 {-1.87/11 3} Cb0 {-0.33/11 3} 43. Rb3
{-1.84/12 3} Ca0 {-2.14/13 3} 44. Rb9+ {+0.08/11 0.5} Ad9 45. Rb1
{+0.01/12 3} Rc5 {-0.01/11 2.0} 46. Ra1 {-1.99/13 3} Cb0 {-2.01/13 3} 47.
Rb1 {+0.01/13 3} Ca0 {-0.01/14 3} 48. Ad2 {-1.99/12 3} Rc0+ {-0.01/11 0.5}
49. Ke1 Rc3 {+0.00/13 3} 50. Ra1 {-2.00/13 3} Cd0 {+0.00/13 3} 51. Ke0
{-2.00/14 3} Cxd6 {+0.00/13 3} 52. exd6 {-2.00/15 3} Rxi3 {-2.00/14 3} 53.
Rxa5 {-2.00/14 3} Rd3 {+0.00/14 3} 54. Re5+ {-2.00/14 3} Afe8 {-2.00/15 3}
55. Re6 {+0.00/14 3} i5 {-2.00/15 3} 56. Ec0 {+0.00/14 3} Rxd2 {-2.00/15 3}
57. Ae1 {+0.00/14 3} Rd1 {-2.00/15 3} 58. Ad0 {+0.00/14 3} Ee7 {-2.00/15 3}
59. Ee2 {+0.00/14 3} Af9 {+0.00/14 3} 60. Rxe7+ {-2.00/14 3} Afe8
{-2.00/15 3} 61. Re6 {+0.00/14 3} i4 {+0.00/14 3} 62. Ae1 {-2.00/14 3} Kf9
{-2.00/14 3} 63. Ad0 {+0.00/13 3} Af7 {-0.01/14 3} 64. Ri6 {-1.99/13 3}
Afe8 {-2.01/14 3} 65. Ri9+ {+0.01/13 0.5} Kf8 66. de6 {-1.99/14 3} Ri1
{-2.01/14 3} 67. e7 {+0.01/13 3} Ri3 {-2.01/13 3} 68. Ke1 {+0.01/12 3} Ri1+
{-2.01/14 0.5} 69. Ke0 Ri0+ {-2.01/14 3} 70. Ke1 {-1.99/14 3} Rxd0
{-2.01/14 3} 71. Rxi4 {-1.99/13 3} Rf0 {-2.01/14 3} 72. Eg0 {-1.99/13 3}
Rf1+ {-2.01/14 3} 73. Ke2 {-1.99/14 3} Rf2+ {-2.01/14 0.5} 74. Ke1 Rf0
{-0.01/14 3} 75. Ri9 {+0.01/13 3} Rf1+ {-2.01/14 3} 76. Ke2 {-1.99/14 3}
Rf2+ {-0.01/14 0.5} 77. Ke1 Rf0 {-2.01/15 4} 78. Ri6 {-1.99/14 3} Rf1+
{-2.01/14 5} 79. Ke0 {-1.99/15 3} Rf0+ {-2.01/15 0.5} 80. Ke1 Kf9
{-2.01/15 3} 81. Ege2 {+0.01/14 3} Rf1+ {-2.01/15 0.5} 82. Ke0 Kf8
{-2.01/15 3} 83. Rh6 {-1.99/14 3} Rf0+ {-0.01/14 0.5} 84. Ke1 Rf1+
{-2.01/15 0.1} 85. Ke0 Rf3 {-2.01/15 3} 86. Rh8+ {+0.01/14 0.5} Kf9 87.
exe8 {+0.01/14 3} Axe8 {-2.01/17 3} 88. Rxe8 {+0.01/16 3} Rf1 {-2.01/17 3}
89. Rd8 {+0.01/16 3} Rf0+ {-0.01/16 0.5} 90. Ke1 Ke9 {-0.01/16 3}
{Xboard adjudication: Trivial draw} 1/2-1/2

[H.G.Muller]

For Xiangqi "trivial draws" should be un-ticked in the Options->Adjudications menu. Apparently I forgot to make that default setting by adding /triviaDraws=false in the xq.ini file, which contains the special settings for xiangqi.

Trivial draws adjudicates games that are unwinnable except through gross blunders that even a 1-ply program would see in western Chess, like KRKR, KBKN. It is not adapted for Xiangqi. (I would not really know how.) It does not count Elephants, so it considers the game you show as KRKR. In this particular case this seems justified; positioning the defending Rook in front of your King and then just moving it along that file, and dodging sideway checks by moving the King between 8th and 9th rank does seem a trivial way to draw.

The option is intended to waste too much time while testing in waiting for a 50-move draw when one of the engines avoids repetitions because it thinks it is ahead. (Like the one with the Elephants.) There might be cases where it does not work in Xiangqi, though, (KHHK?), so it should really be switched off. Even /testClaims should be switched off, because I am not sure any perpetual claims by the engines s will be correctly recognized. (I don't know any engine that makes result claims other than checkmate, so I never bothered to fix that...)

[Nguyen Pham]

I see only very few cases in Xiangqi are trivial draw such as:
- none side has attackable pieces (R, H, C, P)
- one or both sides have pawns but they all are "old" (in the last ranks)

Some other cases someone thinks draw but actually they requires both players have some basic skill to play draw and/or none doesn't want to "suicide". For example the case you have mentioned KHKH usually is a draw except some positions (which one side can win from 1-tens plies) and none sacrifices his horse nor does perpetual check.

Some of main differences between chess and Xiangqi are that Kings can move in very limited area and one should avoid to "face" the other. Those make all trivial draw cases of chess can't adapt to Xiangqi.

I think you may implements the two cases above for Xingqi (as trivial draw) or we simply turn off that function and wait for 50-move draw or 3th-repeats

[H.G.Muller]

WinBoard distinguishes between "theoretical draws", in which no checkmate position is possible no matter how you arrange the pieces, (e.g. two bare Kings against each other), and "trivial draws", which can only be won if the opponent plays some obvious suicide move. In western Chess the FIDE rules specify that a game is finished as soon as a theoretical-draw position is reached. There is no need for any of the players to claim the draw. So WB automatically terminates such games, and it is not even a user option to allow the game to go on. The Xiangqi equivalent to this would be "defenders-only" positions like KEEAAKAA, as all attacking pieces (apart from the stale Pawns you mention) do have mating potential. (Mainly because stalemate counts as a win).

You are right: I definitely should program these for Xiangqi as well. (Currently I just disabled this adjudication in Xiangqi, to prevent WB declaring a draw in KHK.) The position 3ak1P2/4a4/8/8/8/8/8/8/8/4K4 b is a stalemate, though, so even a last-rank Pawn can sometimes win. On the other hand, KCEEK is a theoretical draw. Are there any others? (Perhaps KCEEKA, but not KCEEKAA, as in KCKAA a help-mate is possible.)

The "trivial draw" option is intended for end-games like KRKR, and adjudicates after 3 moves in that end-game, which is enough to capture any tactically non-quiet initial position (e.g. R8/8/5k3/4r4/8/8/8/8/8/3K5 w; 1.Rf9+ Ke7 2.Re9+ Kf7 3. Rxe6). This should also include the mentioned KAAKP and KCKAA, then.

[Nguyen Pham]

Very interesting. I have totally missed the case the old pawn can win!!!

I think we may firstly discuss / re-define what is "trivial" in xiangqi. As I understand all trivial cases of western chess are: a) none can win/lose b) one may win in 1 ply (half move) thus the opponent is easy to avoid suicide move.

For a) Xiangqi has cases: both have no attacking piece; KCK, KCKE, KCKEE, KCEKE...; KCKA, KCEKA...; KPK, KPKP, KPKA, KPKE... (all pawns are old); (any else?)
For b) the case of mating by old pawn and the case of KCKAA can win only in 1 ply so they can be counted as trivial draws.

We may consider a higher ply for Xiangqi (to solve KRKR) but what is number still "trivial"?

In the case of your position KRKR, what happens if after 3 moves the board becomes your one?

[Nguyen Pham]

Some are trivial draw:
- KCKC, KCEKC, KCEEKC, KCEEKE, KCEEKCEE

If we don't count that one can lose by suicide, there are some:
- KPKEE, KPKAE, KPKAAE, KPKAAEE... (P can be in any position)
- KHKP (P passed the river)
- KHKAAEE

[H.G.Muller]

I guess any number of "old Pawns" on either side falls under (a). KPPKA can have a stalemate position, though.

The 'trivial draw' case is not supposed to be iron-clad. An engine that searches less than 6 ply might fall for the KRKR trap (both in Chess and Xiangqi), but virtually any engine will reach this depth at any time control in such a simplified position. If one is playing engines where there is doubt, the option should be switched off. This is why it was made optional. The KRKR case was important in Chess, because it has a very high frequency of occurrence. The 3-move delay was built in because sometimes engines do see forced win in a more complex situation that will go through KRKR (or KNKN), forcing the opponent to capture the last queening Pawn on a square where the Rook is doomed 3 moves later. So although no serious engine would walk into this trap from another KRKR position, they might be forced into it by conversion from a position with more material. The same holds for KBKB, KNKB or KNKN.

In Xiangqi I guess that KRKR with any number of A, E or old P on either side should be a trivial draw. Similar with KHKH, or even KHKP when the Pawn is promoted. (Can it aways promote? Even KHEEAAKP seems trivial to draw with a promoted P, but when the opponent has E a Pawn might not be promotable.) KPKP is similar, as it also relies on stalemate, and possession of a single promoted Pawn protects you from that. I noticed that even something like KCEEAAKAP can be trivial to draw if Pawn stays on the rank just before the Palace.

There are also the cases of 'overwhelmingly strong defence'. E.g. KPKEEAA is trivial to defend, and my impression is that this holds up to KPKA (but I am not a player, and have no XQ tablebase generator yet, so I might be wrong). How stupid would you have to be to lose in KHKAA or KHKE (measured in plies)? And KRKEEAA? These are all good candidates for 'trivial-draw' adjudication: good engines can be expected to reach a draw with 100% certainty, but the rules do not allow them to claim one. Note that we don't have to be exhaustive here; it is mainly a time-saving feature for engine-engine testing, and if we miss a case, it only means some time will be wasted before the game gets drawn by repetition or 50-move rule.

[edit] Our last two posts crossed each other!

[H.G.Muller]

KCEEKCEE even seems a theoretical draw? I cannot conceive any mates...

Even with a single A or E defender it is quite trivial to survive against a pawn, (KPKA,KPKE) right?

[Nguyen Pham]

In the cases I have posted, there are some three dots means that we can add similar cases (so KCEEKEE is similar to KCEKEE). I will list them fully later.

The case KRKAAEE is a famous one in Xiangqi. Usually it is considered as a draw. However, there are some positions (actually a lot) the Rook side can win after a lot of exactly moves (you can visit my home page xqfan.com and download the freeware EON to watch that endgame). So if one loses the game he may be not a dump but not learn enough. Clearly that endgame can't not consider as a trivial draw.

KCEEAAKAP is not a draw, even the pawn locates before the palate as you mentioned. The Canon side with the help from King and Advisors (such as 3k5/4a4/9/9/9/9/2p6/3AKA2E/9/2E4C1 w), can thread to capture the advisor and can capture the advisor or pawn, change to KCAAEEKA or KCAAEEKP, which can win later.

KHKH somewhat is similar to KRKR, one if lucky can win too. E.g, the position 4k4/9/4h4/9/9/9/6H2/9/9/4K4 w is a mate in 6.

KHKP, KPKA are not "pure" draw, there are some situation the strong side can win.

[H.G.Muller]

In the cases I have posted, there are some three dots means that we can add similar cases (so KCEEKEE is similar to KCEKEE). I will list them fully later.

Yes, but notice the extra C I wrote. This was where both sides had a Cannon, and then only Elephants.

The case KRKAAEE is a famous one in Xiangqi. Usually it is considered as a draw. However, there are some positions (actually a lot) the Rook side can win after a lot of exactly moves (you can visit my home page xqfan.com and download the freeware EON to watch that endgame). So if one loses the game he may be not a dump but not learn enough. Clearly that endgame can't not consider as a trivial draw.

OK, if this longest forced win is more than 3 moves deep, we should not consider it trivial.

KCEEAAKAP is not a draw, even the pawn locates before the palate as you mentioned. The Canon side with the help from King and Advisors (such as 3k5/4a4/9/9/9/9/2p6/3AKA2E/9/2E4C1 w), can thread to capture the advisor and can capture the advisor or pawn, change to KCAAEEKA or KCAAEEKP, which can win later.

OK, I see. You could attack an A on e8 using K as platform

KHKH somewhat is similar to KRKR, one if lucky can win too. E.g, the position 4k4/9/4h4/9/9/9/6H2/9/9/4K4 w is a mate in 6.

OK. To make the limit 6 moves in stead of 3 is probably also not trivial anymore.

KHKP, KPKA are not "pure" draw, there are some situation the strong side can win.