Winboard Forum

I include a link to an updated version of the pack (Chess16), which includes a new version of Winboard called Winboard Zeta (Alex Guerrero) and all Hispanics chess engines updated to the current date.

http://www.mediafire.com/file/k1sl26djp ... hess16.zip (163 Mb)

Winboard Zeta has some improvements over Winboard X:

- Supports opening books in 3 formats; Polyglot (bin), Chessbase (CTG) and Arena (ABK). For games with humans and between engines.
- Supports tablebases Gaviota.
- A change in appearance to the handling of bitmap pieces, textures and background pictures on the board, in addition to creating custom themes.
- Pronounce moves and dialogues (dialogues now only version spanish) which seems to be talking.
- Rated game. The program gives you a rating and if the engine has an Elo.
- You can change Elo in the menu for uci engine with options UCI_Elo and UCI_LimitStrengh and use this Elo for rating.
- Match between engines with opening sequential or random from positions PGN and EPD files.
- Includes an external engine manager which can install, edit and delete engines easily.
- Includes external tournament manager which can easily make tournaments between engines, has options to quickly locate games with problems, shows results tables and Elo.
- Help on Winboard Zeta in Web Page and pack (only version spanish)

Web Page Hispanisc chess engines (spanish) --> https://sites.google.com/site/motoresdeajedrez/Home

Web Page Hispanisc chess engines (english) --> https://sites.google.com/site/hispanicchessengines/

Sorry, I can not update this page in English, the site is being updated only in the Spanish language.

Native support for CTGs without adapters? FanTasTic.

Sorry to say I have at the moment no possibility to check this out -
but from the readings I can tell this Zeta is something special and extraordinary!

Thanks!

Big thanks to Alex Guerrero (and Pedro) for this greatly improved WinBoard!

I have previously looked at WinBoard X and this new version - WinBoard Zeta
in fact has most of the new things one could wish for! Greatly improved graphics,
with lots of wooden textures + you can add your own - and all those new possibilities
with opening books... TB Gaviota support and
now even possible to play rated games!

Kyodai wrote:Big thanks to Alex Guerrero (and Pedro) for this greatly improved WinBoard!

I have previously looked at WinBoard X and this new version - WinBoard Zeta
in fact has most of the new things one could wish for! Greatly improved graphics,
with lots of wooden textures + you can add your own - and all those new possibilities
with opening books... TB Gaviota support and
now even possible to play rated games!

Thanks to you Kyodai.

I am glad that you enjoy playing chess with that.

This is all really neat. Fantastic work!
Is the source code available somewhere and have you talked to Arun or H.G.Muller about incorporating some of your changes into main xboard/winboard branch?

A lot of this stuff like internal tournament/engine manager, and opening positions from pgn are included in the main winboard branch already. But bit map pieces might be nice as an option. Currently chess fonts can be a little limiting as there are only so many. Also the extra opening book handling would be very useful as we are only limited to polyglot's .bin format and converting can be a real pain.

Well, using the bitmap pieces is already in (but I did not post the source yet). This is a trivial change (especially since XBoard already could use external bitmaps, so the option -bitmapDirectory to control it already existed, and it thus involves only loading of the bitmaps from a file rather than from the resource). All the effort for this feature is in preparing the bitmaps: because bitmaps, unlike fonts, do not scale, a separate set has to be prepared for each and every square size. But this is what Alex did, so they are available.

The borders around the board I am still working on, as it is a bit more involved: It also affects the translation of mouse-click coordinates to squares. This will require some testing, to make sure I do the coordinate transformation in every place where it is needed. (This code was changed pretty heavily since Winboard_x, so it would not be possible to directly use the WinBoartd zeta patch.) But yesterday night I was already at a stage where the displacement seemed to work (although I did not check the Atomic explosions yet), with a fixed border width of 10 pix. So the only thing I have to do is set the correct (square-size-dependent?) margin width, load the background bitmap, adapt its size and print it in there.

OK, done:



Beta version is in the download http://hgm.nubati.net/WinBoard-Portable.zip .

neat how do you enable it?

Oh i see the /border "" command in the wb.ini. I was thinking would it be possible to disable it with use board textures disabled in the GUI? Looks rather ugly without em and doesn't make sense to have it without the square textures.

This could easily be done. I could also make a special option -useBorder for it. I am not sure the border would be totally useless without textures. People could for instance use it to have the square coordinates outside the board, when saving positions as diagrams (using a white border). But in that case an option -borderColor might be useful. (Currently non-existing border bitmaps give you a border in the whitePieceColor.)

The intention of course is to make all this controllable from menus (together with some existing options, like the texture bitmap files, which are only controllable through options in 4.6.x). Something like this:

Well I like it! A lot actually. Another thing on the same lines would be some way of handling chess font colors. It would be nice if the bitmap color picker could handle it, but i guess the fonts have both a background and foreground color to handle. not sure how you could put that in as well. Though doesn't xboard do this with its pixmaps? Also, like in xboard bitmap pieces may need the option to be their original colors. As it is, the black pieces tend to get distorted if the bitmaps weren't monochrome to begin with.

Note I updated it a little. (And now I still have to make it really do something, other than just altering option values that will only be re-interpreted during the initialization of the next session...)

Indeed, font-based pieces have different options for setting their colors than the built-in bitmap. Where the white pieces of the latter are controlled by -whitePieceColor, with font-based rendering two colors are specified (to make a gradient) with -fontPieceForeColorWhite and -fontPieceBackColorWhite. This has always struck me as a pretty bad idea. (But it was inherited from Winboard_x, so for backward compatibility reasons...) A more sensible design would be to use the -whitePieceColor as foreground color in the gradient. Then it could already be interactively set through the Board Options dialog. The background color of the gradient almost always has to be black to provide a natural shading effect (which was the purpose of the gradient). Allowing the user to pick it is over-doing it, IMO. So perhaps I should simply deprecate the WB_x color options (for the time being let WB ignore them, and use -wpc / -bpc and hard-coded black in stead to create the gradient on font pieces).

An alternative would be to retain the separate options to keep the WB_x purists happy, but let the Board dialog set both the built-ins color as well as the font foreground color.

The WinBoard zeta bitmaps are full-color bitmaps; there is noway to adjust their color through any options.

Pixmaps can specify colors in symbolic form, (like 'darkSquare'), and XBoard uses that to redefine the color later. In multi-color pixmaps that does not really work. (You could at most redefine one of the colors through the color options). In the SVG/PNG version I added code to process the images after scaling, by analyzing the RGBA value of each pixel, and assume it is a mix of pure white, black and transparent. This allows you to determine the weight of each of these. Then I replace one of the colors by the color of the -wpc or -bpc option, and add them again with the derived weights. That way I can recolor bitmaps that are already smoothened by anti-aliasing. I added an option to suppress that post-processing of the scaled bitmaps, which can be used for multi-color images (where the black/white/transparant assumption is not valid, and the recoloring wuld lead to very weird effects).

Anti-aliasing seems a bit of a problem in the WinBoard zeta pieces: if you look carefully, you will notice that some piece sets have stray light or dark pixels around their edges. Some pieces also exhibit nasty instabilities of their edges when you start dragging them. The problem is probably that the plot library on which WinBoard is based does not really support an alpha channel.

Fantastic great work.!!! Congratulations.
I wonder how to create at the WinboardZeta Engine Manager engine files of Java chess engine, UCI and winboard ,which typical executable is "java -jar filename.jar", for example the Java chess UCI engines ChessNovice or Cuckoo or the winboard Java engines such as Bembose or Cheetah.
Best regards,
Pablo Urzua

OK, the version at http://hgm.nubati.net/WinBoard-Portable.zip now has this working. You can both add and delete themes there.

Pablo wrote:Fantastic great work.!!! Congratulations.
I wonder how to create at the WinboardZeta Engine Manager engine files of Java chess engine, UCI and winboard ,which typical executable is "java -jar filename.jar", for example the Java chess UCI engines ChessNovice or Cuckoo or the winboard Java engines such as Bembose or Cheetah.
Best regards,
Pablo Urzua

Gracias Pablo.

Habia olvidado los motores java porque generalmente los adapto con inbetween o uso una utilidad que los convierte en .exe.

Pero ya estoy trabajando en ello. Con los winboard es facil incluso ya lo hice pero con los uci es un poco mas complicado.

Si tienes algunas sugerencias son bienvenidas.

H.G.Muller wrote:OK, the version at http://hgm.nubati.net/WinBoard-Portable.zip now has this working. You can both add and delete themes there.

Wow that was fast, really great work! looks great! I love the saved themes that is just like the chess engine dialog. Also I like it is all stored right there in the winboard.ini with all the other settings. As oppose to the separate theme files. Very elegant.

I noticed a couple minor things. I found that it would save the directory for the boarder .bmp without quotes in the .ini file. Problematic if the directory has spaces. Also for some reason the checkbox "use chess font" isn't saved in the theme. Or at least i think that's the case.

Thank-you!

OK, thanks for testing. I will check it out, these are probably things I forgot. When doing this I stumbled on a bug that must have been there for ages (taken from Winboard_x): the option type under which the board textures were saved was ArgString, rather than ArgFilename. The difference is that in quoted strings a backslash is used as an escape character, while in Windows filenames it should of course stand for itself. So when I saved "WinBoard\textures" in the ini file, it would be read back as "WinBoard extures" because \t is the escape for Tab!

The likeness with the Load Engine dialog is no coincidence: I cloned most of the code for that dialog to make the new one. This means it should also be possible to group themes with "# GROUPNAME" and "# end" lines in the -themeNames, just like engines, and expand / collapse the groups in the listbox like it is a tree widget. (But I have not tested that.)

It turns out I misunderstood how these font piece colors work. They are not describing the gradient, but the 'BackColor' gives the color of the symbols of the font (the 'outline'), while the 'ForeColor' specifies the color with which the open spaces with them are filled. The latter is used as a gradient dropping to half the brightness in the shadowed part (in the lower-right square corner). This is rather opposite from usual terminology for font coloring, where 'foreground color' means the color of the symbols, and background everything in or around them.

Since piece fonts usually depict white pieces with thin lines, and black pieces as ultra-bold blobs, this means that one percieves the white pieces as having the ForeColorWhite, and black pieces as having the BackColorBlack. The outline of the white pieces (conventionally black) is then in the BackColorWhite, while the details on black pieces (conventionally transparent in WinBoard and the whitePieceColor in XBoard) are inscribed in the ForeColorBlack (with gradient).

So it would be logical to associate -fontPieceForeColorWhite with -whitePieceColor, and -fontPieceBackColorBlack with -blackPieceColor (i.e. set them through the same color controls in the View -> Board dialog), and define -fontPieceBackColorWhite as black and -fontPieceForeColorBlack as white (as transparency is not an option). There probably is little demand for altering the latter two, so leaving a command-line option as the only way to do it doesn't sem to bad.

There is only one snag: with the option 'All White', (or in a Shogi font), the 'black' pieces would also have thin outlines, and would be percieved as having the ForeColorBlack, while the BackColorBlack should preferably be fixed to black. Rather than forcing the user to swap the colors when he is using pieces with thin outline for both sides, it would be better to let WinBoard do this automatically, and use the BackColorBlack for filling the inner area (which normaly would be used for the fat symbol), and use the BackColorWhite for drawing the outline. This would force white and black to always use the same color for the narrow outline, however. I am not sure this is a problem; in fact it seems the option 'All White' is superfluous for font-based pieces, as one could simply define the -fontPieceToCharTable such that black pieces map to the same font symbol as the corresponding white pieces. A Shogi font would also not really need the option 'All White', as it usually provides the upside-down pieces as different symbols of the font. Coloring their outline black, and their interior white, is actually exactly what you need to give them the same colors as the white pieces.

So the bottom line seems to be:

* Use the -whitePieceColor control in View -> Board to set -fontPieceForeColorWhite when 'Use piece font' is ticked
* Use the -blackPieceColor control in View -> Board to set -fontPieceBackColorBlack when 'Use piece font' is ticked
* Use the white-piece outline color and black-piece outline color for black-piece outline and interior when rendering in 'All white' mode

[edit] Oh sh*t... I messed up! When I ported the WinBoard option handling to XBoard (I think that was in 4.5.0), I had to account for the completely different representations of colors in the two. So the color options do not directly point to a color variable, but contain a number, which is then passed to a function that uses it as index in a table with pointers to the actual color variables, which then does the conversion to the required format, and stores it there. In WinBoard I accidentally swapped the Fore and Back colors in that table. So the ForeColor option now sets what internally was the BackColor, and vice versa... This is why the naming was so strange.

All the more reason to deprecate these options. I guess I will let the font pieces use the same -wpc and -bpc for their main color, and then introduce two new options -pieceOutlineColor and -pieceDetailsColor for the minor colors of font pieces.

Alex,
Me interesa de sobremanera la utilidad que mecionas para transformar los ejecutables java en ejecutables .exe. Favor indicarme de donde puedo bajar dicha utilidad, siempre que no sea compilar el programa completo de nuevo.
Me alegro mucho que hayas encontrado la solución para instalar los motores winboard java en WinboardZeta..
Saludos,
Pablo Urzua

Alex Guerrero wrote:

Pablo wrote:Fantastic great work.!!! Congratulations.
I wonder how to create at the WinboardZeta Engine Manager engine files of Java chess engine, UCI and winboard ,which typical executable is "java -jar filename.jar", for example the Java chess UCI engines ChessNovice or Cuckoo or the winboard Java engines such as Bembose or Cheetah.
Best regards,
Pablo Urzua

Gracias Pablo.

Habia olvidado los motores java porque generalmente los adapto con inbetween o uso una utilidad que los convierte en .exe.

Pero ya estoy trabajando en ello. Con los winboard es facil incluso ya lo hice pero con los uci es un poco mas complicado.

Si tienes algunas sugerencias son bienvenidas.