New WinBoard release

[hgm]

I just released WinBoard 4.3.13.

New features compared to 4.3.12 are:

- Engines can now claim a draw that occurs only after their move by sending "offer draw" before the move, as WinBoard will treat offers in a 3-rep or 50-move situation as claims.
- Draw offers are only passed to the opponent after the offerer also gives its move
- Time-odds games are supported
- Search time is now stored together with depth/score in the PGN
- WinBoard now can receive options from the engine command line, so that options that follow the engine are possible (with any WB tournament manager)
- FRC is now fully supported (local and ICS play)
- There are 5 more fairy pieces, (22 piece types per side) amongst which several wildcard pieces (that may do any move, even when legality testing is on)
- Most fairy pieces are now also available as bitmaps in board size 'petite'
- Archbishop and Chancellor are available in 9 formats

Various bugs that occurred in 4.2.12 are fixed:
- KQKR is no longer considered trivial draw )i.e. black Queens are now counted as Queens, not Rooks...)
- KBKB with like Bishops is recognized as insufficient mating material
- The problems with Shatranj in ICS mode are fixed
- Sideway Pawn moves in Xiangqi are no longer considered e.p. captures
- Sideway steps of the Unicorn in Knightmate are recognized as castlings

All features of 4.3.12 and its predecessor WinBoard_x of course remain resent as well, amongst which the draw adjudications, mate- and draw-claim verification, font-based piece rendering, user-defined board textures, variable board sizes, showing of the holdings in Crazyhouse and other games with piece drops, variants Shogi and Xiangqi.

Downloads, one for the executable, one for the complete source code, is already available from Fonzy's website ( http://www.geenvis.net ).
Beware, it is still a beta version! Let me know about any problems.

[hgm]

A screen shot:

[jdart]

I notice some odd behavior:

There's a "New FRC Game" menu item on the File menu. If you select this you get a dialog to set the starting position. But after selecting this and clicking Ok, it seems that you always get the standard (non-FRC) starting position.

But if I go into the Variant dialog and set the variant to "FRC" then the "New FRC Game" menu item works as expected.

Wouldn't it make sense to set the variant to FRC automatically if the user has selected "New FRC Game"?

--Jon

[hgm]

Yes, it would. Except that in the future, I plan to rename the "New FRC game..." menu option to "New Opening Shuffle...", and allow it to shuffle the start position of any variant. This especially to also implement CRS, the 10x8 variant of FRC.

I still have to work out, though, on generating shuffles with different piece sets with equal probability distribution, and I did not want that to hold up the release. I guess it would have been more logical to disable this menu item outside of FRC, but as I eventually want to have it always available, I was too lazy to do it.

In the future the shuffle will be such that in variants with orthodox castling you will get a shuffle with central King and corner Rooks, while in castling-less variants you can get any shuffling, and for FRC and CRC you will get King-between-Rooks setups, and you will stay in the selected variant. This seems the most orthogonal way to do it.

But for now, "New FRC game..." only selects a new FRC opening position, which becomes used only when you select variant FRC.

[hgm]

Although no outright bugs hav been reported yet, the number of possible improvements is already abounding. So for the next version, the to-do list now is:

* generalize opening shuffle to other variants (in particular CRC).
* add support for node-count-based time control
* add support for Berolina Pawns (which capture straight ahead and move diagonal, so that WB now mistakes their moves for e.p. captures, leading to erroneous disappearence of enemy Pawns).
* add an /autoKibitz option, which would automatically kibitz the last PV-info line of the engine to the ICS in zippy mode

If you have more ideas or requests, please post them here!

[hgm]

Another idea might be to add a menu item to save the display as a graphics file, to make it easier to use WinBoard as a diagram generator.

[Charles B.]

When playing against an engine the GUI automatically picks up the username that the computer is assigned, at least this is my experience on the old computer I use. Would it be nice (maybe) to have the ability to input a username through the GUI instead? So that the saved PGN file and the GUI shows that human username. Could this be done without breaking anything?


Also it would be nice to find out if people running Windows 98 experience any anomalies while running Winboard F, for example: window overlap on program start, shadows when using piece fonts after moving the windows to their desired place (graphic below). I didn't mention the shadows when using piece fonts before because I only tried using piece fonts in Winboard F again yesterday. The shadows don't appear everytime the windows are moved in place, just some of the times.





There is no guarantee if Winboard F were compiled with a different compiler that my results with the program would be any different than they are now. I tried my hand at using a free compiler in the past but Windows Me is not supposed to be a good platform for that, and together with my lack of knowledge on how to do it properly, the result was a failure.



It will be interesting to see your "New Opening Shuffle..." button in action. It is difficult for me to visualize what you have planned so that it covers all of the intended variants.

[hgm]

The username stuff sounds feasible. I will put it on the to-do list.

The 'shadows' are weird! I've never seen anything like it. (But I hardly ever use font-based rendering, and it is something Allessando Scotti put in.) It seems that the Pawn outline bitmaps derived from the fonts are somehow replaced by off-setted Rook outlines.

Can you check for me if it is tied to a certain board size? If I drag the WinDow, for reasons I don't understand it sometimes automatically scales the board too.

It could be that some working space of the graphics library is set too small for the large number of piece bitmaps that have accumulated, so that when constructing the bitmaps it starts to overwrite itself (at the larger sizes). I hope I can figure out what is going on here...

[Charles B.]

As far as the overlays appearing it doesn't appear to be board size related. Normally I use the moderate board size and choosing a board size above or below that one did not prevent the overlays from appearing. Also I need to stress that sometimes the overlays do not appear. Though I am almost certain that it isn't my graphics card causing this. Operating System? I don't know. I don't remember this happening in your earlier versions of the program.


It also isn't just a rook that appears as shown below. These are from the moderate board size. The board sizes smaller than moderate that I tried had the overlays on the pawn rows.











This screenshot is from I believe the bulky board. Though in the test I just did sometimes the overlays were on the pawn rows and knights.




It doesn't clear up when the pieces move.

Can you check for me if it is tied to a certain board size? If I drag the WinDow, for reasons I don't understand it sometimes automatically scales the board too.

I think I know what you mean by drag the window, but if I go to drag the board from an edge the board size doesn't change but the overlaid pieces on the pawns change, or else they change their color.

[Charles B.]

Just to let you know that when I flip the board the overlays follow the white pieces to the top of the board. The black pieces when at the top or the bottom of the board haven't shown the overlays, so far.