WinBoard + xboard 4.3.14 released (finally)!

[bob]

I suppose my main concern would be this: Did you play lots of normal engine-engine matches with no problems, and also did someone play on ICC for a number of games? When we tried pre-HGM recent versions, several of us were seeing these unexplained hangs/losing on time on ICC (I rarely use xboard for engine-engine testing myself) and I was getting a number of questions from users seeing the same problem. Whatever version I am currently using on ICC worked perfectly and I decided to stick there to keep life simple.

I'll give it a whirl soon however...

But I really would like that game history window and stuff. Even an analysis window separate from the ICC chat window.

[bob]

I suppose my main concern would be this: Did you play lots of normal engine-engine matches with no problems, and also did someone play on ICC for a number of games? When we tried pre-HGM recent versions, several of us were seeing these unexplained hangs/losing on time on ICC (I rarely use xboard for engine-engine testing myself) and I was getting a number of questions from users seeing the same problem. Whatever version I am currently using on ICC worked perfectly and I decided to stick there to keep life simple.

I'll give it a whirl soon however...

But I really would like that game history window and stuff. Even an analysis window separate from the ICC chat window.

[hgm]

I play almost non-stop engine engine games with WinBoard + PSWBTM. But not every aspect of WinBoard is exercised that way, as PSWBTM only invokes it for single-game matches. I hardly ever play on ICS. I tried a few FRC games there (playing in zippy mode and observing), and even fewer Shatranj games, and observed some Crazyhouse games, and that all seemed to work. For really heavy testing, I am dependent on others, as WinBoard just can be used in too many ways to test everything on my own to a degree that would catch rare events. This is truly a beta version. I only played one game with xboard.

The ICS code is hardly touched by me. That means if there were bugs there, they are probably still there. Most of the time I am not aware of pre-existing bugs, and my policy in making changes is to keep them very localized and totally transparent when the set of conditions where I want them to be active is not exactly fulfilled. That unfortunately also means that I am very likely to preserve pre-existing bugs .

If someone can send me a debug file of a game that went clearly wrong, I can try to hunt down the bug and correct it. Otherwise there is little hope.

[Guetti]

I just compiled this new version of xboard on my Mac, it compiled and starts fine with and without Xaw3d. And didn't make any engine matches yet.
One small problem, I tried to convert the winboard bitmaps with the convert utility in pixmaps, however this crashes on my core2duo with a bus error.

Starting program: /Users/andreas/Chess/xboard14/pixmaps/convert
Reading symbols for shared libraries ++. done
try ../winboard/bitmaps/p21o.bmp
../winboard/bitmaps/p21w.bmp loaded

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x8fe0139c
0xffff884c in ?? ()
(gdb) backtrace
#0 0xffff884c in ?? ()
#1 0x90529b8c in __sfvwrite ()
#2 0x905c33d0 in __vfprintf$LDBL128 ()
#3 0x905c447c in sprintf$LDBL128 ()
#4 0x000029d8 in main ()

[gerold]

Very good H.G. Thanks. I fine this version very user friendly.

Best to you,

Gerold.

[hgm]

I just compiled this new version of xboard on my Mac, it compiled and starts fine with and without Xaw3d. And didn't make any engine matches yet.
One small problem, I tried to convert the winboard bitmaps with the convert utility in pixmaps, however this crashes on my core2duo with a bus error.

There should not be any need for you to convert the bitmaps: all pixmaps were already included in the source distribution. Or did you change some of the windows bitmaps?

I indeed see a big oops in the convert.c source: in main(), name is declaired as a pointer, while it should be an array. (char *name should become char name[80]). So name is just using any memory area for building the string with the pixmap name that the uninitialized pointer happened to point to, and I was just lucky that in my case this happened to be a piece of menmory that was available, and not used for anything else!

[Guetti]

I just compiled this new version of xboard on my Mac, it compiled and starts fine with and without Xaw3d. And didn't make any engine matches yet.
One small problem, I tried to convert the winboard bitmaps with the convert utility in pixmaps, however this crashes on my core2duo with a bus error.

There should not be any need for you to convert the bitmaps: all pixmaps were already included in the source distribution. Or did you change some of the windows bitmaps?

I indeed see a big oops in the convert.c source: in main(), name is declaired as a pointer, while it should be an array. (char *name should become char name[80]). So name is just using any memory area for building the string with the pixmap name that the uninitialized pointer happened to point to, and I was just lucky that in my case this happened to be a piece of menmory that was available, and not used for anything else!

I just thought I would then get the nicer looking board of winboard, that's why I tried to convert them after reading the Readme in pixmaps.
For winboard 4.2.7, I had my own pieces bitmaps for standard chess, but the new version doesn't use them anymore, because probably it needs more pixmaps.

$xboard -ncp
Loading XPMs...
1 2 3 4 5 6 Error -1 loading XPM file "/Users/andreas/Chess/pieces/dyche/.ll40.xpm"


$Chess/xboard-4.2.7/xboard -ncp
Loading XPMs...
1 2 3 4 5 6 light square dark square Done.

Then in .Xresources I had an entry
xboard*pixmapDirectory: ~/Chess/pieces/dyche

Is it somehow possible to have the winboard bitmaps for standard chess in xboard with this nice green and grey squares?

As stated above everything else runs fine. Thanks for you work to improve winboard, and I'm glad changes finally also make it to xboard.

[hgm]

I just thought I would then get the nicer looking board of winboard, that's why I tried to convert them after reading the Readme in pixmaps.

Unfortunately, that doesn't work. The texture of the board squares in WinBoard does not come from the piece bitmaps. The latter are plotted on top of the board, which is drawn first separately. This is quite different than the way it works in xboard: the pixmaps contain both square and piece (requiring each piece to have two versions of the pixmap, one on light, one on dark squares. Yegh!. This also makes it impossible to introduce a third square color, e.g. for the Crazyhouse holdings, without providing yet another complete set of piece pixmaps.)

For winboard 4.2.7, I had my own pieces bitmaps for standard chess, but the new version doesn't use them anymore, because probably it needs more pixmaps.

$xboard_new -ncp
Loading XPMs...
1 2 3 4 5 6 Error -1 loading XPM file "/Users/andreas/Chess/pieces/dyche/.ll40.xpm"
orcabox:~ andreas% Chess/xboard-4.2.7/xboard -ncp

$xboard_old -ncp
Loading XPMs...
1 2 3 4 5 6 light square dark square Done.

Then in .Xresources I had an entry
xboard*pixmapDirectory: ~/Chess/pieces/dyche

I guess this is indeed because there are 22 piece types now in stead of 6. Perhaps we should make the reading routine less critical, that if it does not find a file it simply keeps using the built-in pixmap for that piece (which is likely not to get used at all), rather than giving up.

I guess as long as we don't switch variant or board size during the run (as can be done in WInBoard), it woulld also be sufficient to refreain from trying to load any piece that does not occur in the selected variant. That would require the addition:

Code: Select all

        if(PieceToChar((ChessSquare)piece) == '.') continue;

in the (second) loop over pieces ("for(piece = ...") in the routine CreateXPMPieces() in xboard.c.
I guess a fairly simple work-around would be to provide the files
.ll40.xpm
.ld40.xpm
.dl40.xpm
.dd40.xpm
(note the period at the beginning) as copies of sme other file (say King), i.e. kll40.xpm, kld40.xpm atc. And then do that for all sizes you plan to use (not only 40). In the current code every piece that does not participate in the current variant is named '.', so you would only have to provide that name (in the various color combinations and sizes) to make it work. That is a lot less than supplying all the 22 piece names in 4 color flavors and 18 sizes as copies of some existing piece.

Is it somehow possible to have the winboard bitmaps for standard chess in xboard with this nice green and grey squares?

As stated above everything else runs fine. Thanks for you work to improve winboard, and I'm glad changes finally also make it to xboard.

I am afraid not. Some of the pixmaps are 3-color, so I guess you could also make them more color, but you would really have to create the marble-like background somehow. And tthat pattern would then move with the piece. Plus, I have no idea where the isolated pieces (without square backrground) that appear when you are dragging with the mouse come from. They must somehow be derived from the pixmaps by setting the square color to transparent, but if the square has multiple colors, that probably would not work, and you would drag the piece square an all. (Like is done in monochrome mode, btw.)

This might be one of the more difficult things to implement in xboard, as it is purely a front-end thing, and quite incompatible with the way the xboard front-end now draws piece+square combinations, rather than first drawing squares and then overlaying them with partly transparent piece bitmaps. So we would have to completely overhaul the board drawing code, before we could even begin implementing this.

[Guetti]

I guess this is indeed because there are 22 piece types now in stead of 6. Perhaps we should make the reading routine less critical, that if it does not find a file it simply keeps using the built-in pixmap for that piece (which is likely not to get used at all), rather than giving up.

I guess as long as we don't switch variant or board size during the run (as can be done in WInBoard), it woulld also be sufficient to refreain from trying to load any piece that does not occur in the selected variant. That would require the addition:

Code: Select all

        if(PieceToChar((ChessSquare)piece) == '.') continue;

in the (second) loop over pieces ("for(piece = ...") in the routine CreateXPMPieces() in xboard.c.
I guess a fairly simple work-around would be to provide the files
.ll40.xpm
.ld40.xpm
.dl40.xpm
.dd40.xpm
(note the period at the beginning) as copies of sme other file (say King), i.e. kll40.xpm, kld40.xpm atc. And then do that for all sizes you plan to use (not only 40). In the current code every piece that does not participate in the current variant is named '.', so you would only have to provide that name (in the various color combinations and sizes) to make it work. That is a lot less than supplying all the 22 piece names in 4 color flavors and 18 sizes as copies of some existing piece.

It worked when i provided the .files, however, it is still a lot of work when you have many sizes. I don't quite understand why these .files are needed, if there is no pixmap for a piece of the variant then it could just drop back to the included bitmaps.
I will try to change the source as you suggested to see if I can save the work of generating all .files for all sizes.

Is it somehow possible to have the winboard bitmaps for standard chess in xboard with this nice green and grey squares?

As stated above everything else runs fine. Thanks for you work to improve winboard, and I'm glad changes finally also make it to xboard.

I am afraid not. Some of the pixmaps are 3-color, so I guess you could also make them more color, but you would really have to create the marble-like background somehow. And tthat pattern would then move with the piece. Plus, I have no idea where the isolated pieces (without square backrground) that appear when you are dragging with the mouse come from. They must somehow be derived from the pixmaps by setting the square color to transparent, but if the square has multiple colors, that probably would not work, and you would drag the piece square an all. (Like is done in monochrome mode, btw.)

I think the way xboard handels this is by comparing the piece and square color with the empty square of the same color and subtracting everything that it is the same. It works with complex backgrounds such as marble when done very carefully, but it is a huge mess. One dither operation over the image (i.e. during scaling) and the background is not the same anymore on the resulting image and you will see dots of the background moving with the piece. Because of that, I use only single color square colors for now.

This might be one of the more difficult things to implement in xboard, as it is purely a front-end thing, and quite incompatible with the way the xboard front-end now draws piece+square combinations, rather than first drawing squares and then overlaying them with partly transparent piece bitmaps. So we would have to completely overhaul the board drawing code, before we could even begin implementing this.

And neat way would be to just provide one svg (scalable vector graphics) image for each piece of each color (they have transparent background) and xboard would generate the sizes appropriate.

Here is a page of somebody who drew svg files an manually scaled them for xboard and the result looks very nice. (Although he also introduced shadows, which unfortunately lead to them problem discussed above when moving pieces).

http://linuz.sns.it/~monge/wiki/index.php/Chess_pieces

[Peter Skinner]

Is there something in the new Winboard version to stop automatic time out schemes on ICS servers?

It would be great if every few minutes it sent a string to the server to show some activity.

ICC does have the noautologout option, but FICS doesn't. I would love something for there.