Upcoming WinBoard 4.3.14 release will include xboard!

[hgm]

Zach Wegner and I succeeded in getting the most recent WinBoard sources (which will be released very soon now) to work together with an xboard front-end. Most of the new back-end features are available in this version through xboard command-line options. (Menus will be added only in a later release.) This includes adjudications, extended PGN info, time-odds games, node-count-based timing, and of course all the variant pieces and board sizes.

A screenshot, mailed to me by Zach:

[hgm]

Perhaps this is a good place to ask a question that always occurs to me when I see screenshots of xboard:

Do xboard users really like this representtion of the white pieces, which use the same bitmaps as the black pieces, in a lighter color. I always have grave difficulty focusing on them, they give me the impression of great vagueness, like the pieces are ghosts. The WinBord representation, with a black outline, stand out much sharper.



So give me some feedback. Would you prefer pieces with a black outline, or pieces with an unbordered light color, in xboard?

[Zach Wegner]

Actually, I can answer that question. XPM pieces, the default, look quite nice, with black and white pieces.. I like them more than the Winboard pieces.

The problem is that the new pieces are only supported in bitmap mode, which are monotone. This is yet another reason that I advocate a switch to PNG graphics (or at least some other portable, open standard). Making new pieces would be as simple as creating two simple graphics, one for each color.

Here's a screenshot though, of "normal" xboard:

[hgm]

OK, so we really would want to have built-in XPM files. The sources for this, in the pixmaps directory, are actually also very simple in format, as text strings rather than bitmaps. I could have auto-generated these just as easy from the WinBoard bitmaps. The disadvantage is that there are 4 pixmaps needed for each piece/size: light or dark piece on light or dark square.

The main problem of using any format, is how to make sure that we can include that same format in the binary without converting it to source? To do that for every piece itmap is a real pain.

It would not be very much work to design my own format for a single packed bitmap that includes all WinBoard bitmaps, make a large array from it initialized with hexadecimal integers, that would belong to the backend, and provide front-end routines that extract the bare bits from this array and convert them to the formats required by the front end graphics routines, and then process them as they are processed now.

[Zach Wegner]

That is not a bad idea. The two main aspects I am concerned with are portability, that is, not having to convert the pictures for all the different formats, and sizing, not having to resize the pictures for all the different board sizes.

Using an internal format wouldn't be such a bad idea. There are two snags with it, though: it makes it harder to make new piece bitmaps, and it makes it harder to allow dynamic run-time based bitmap loading of user-specified bitmaps. I don't think having the bitmaps be external from the executable would be such a bad thing. PNG has the advantage of having a full library available that handles all of the dirty stuff, transparency, resizing, etc., and it could stay in the back end.

[hgm]

Resizing without making it ugly is a science in itself, that has lead to the invention and patenting of true-type fonts. I don't think we should have the ambition of re-inventing that ourselves. If resizing is to be done, we should use some form of font-based rendering.

The external format could remain as it is now. Disadvantage: external bitmaps would not be portable between WinBoard and xboard. WinBoard does not provide external bitmaps anyway, and already supports the font-based rendering. I think that if we want to provide scaling, we should use font-based rendering. That would mean we would have to add it for xboard.

As for bitmaps: the current strategy in WinBoard is to pack bitmap files as produced by, e.g. MS Paint, into a resource, and use standard Wndows calls to retreave them from there as Windows monochrome bitmaps. These bitmaps have a very simple structure. The strategy in xboard is to have raw data for the bitmaps as initialized data arrays in the source code, and provide a routine to convert that raw data to a format as is used for the external bitmaps. And then there are several alternative systems, as you showed above, each having their wn built-ins as well as external bitmap files.

I was thinking of replacing that by rendering the built-in pieces as in WinBoard, i.e. based on 3 monochrome bitmaps: one solid, for the black pieces, and an outeline and fill-in for the white pieces.

The format I would use in the source-code file would be to use run-length coding on the raster scan of all the bitmaps, the run-length itself encoded as a Hufman code. That should enormously compress them. The stream of bits would simply be concatenated. In addition, there would be an array of integers, giving the number of the start bit for every bitmap: startBit[size][kind][piece]. The program to make this source file would only need a list of all the piece names (one or two character, so an initialized array of strings), and an array of square sizes. It would concatenate those, plus a final o, s or w to indicate the kind, in three nested loops, to construct filenames of the type dk49o.bmp (the outline for the white 49x49 Dragon King piece), try to open the file, if it was there, extract the data bits from the .bmp file, pack them and add them to the bit data, and initialize the startpointer for that bitmap to the beginning of it. If the file could not be opened, the pointer to its start data would be set to 0. At the end, the data would be written out in C-source format, and belong to the backend.

That is really all. To unpack the data for a requested piece a back-end routine would be provided to do the unpacking f the bitstream starting at a given bit number, to generate a bitmap. The xboard source data and Windows bitmaps use opposite endian-ness to store the data, so the unpack routine should be able to unpack it either way, under control of an argument. Another difference between the xboard built-in data format and the Windowsbitmap is that in the latter the scan lines are multiples of 4 bytes, rather than one. This could be indicated by another arcgument to the unpack routine.

The front-end would then contain routines to create a header to the bitmap (if needed, I think that only Windows bitmaps need a header, the xboard built-n data doesn't), and a call to the unpack routine with the appropriate arguments.

I think I could make all that in a day, now that I already made the utility convert.c to convert a single Windows bitmap file into a xboard built-in bitmap source file.

[hgm]

OK, Zach and I now also have all WinBoard_F pieces converted to pixmaps! No more vague pieces!: