New WinBoard release

[hgm]

Well, it is pretty clear to me what happens (just not why it does... ):

WinBoard draws the white pieces from two monochrome bitmaps, a white one for the background, and a black one for the outline. Normally they match. But is seems here that memory is totally messed up, and that bitmaps of one piece type have overwritten those of another piece type.

I will see if I can reproduce it here, and if there is an easy fix. Probably some scratch memory area has to be declared larger.

[Charles B.]

If no one else verifies the problem I wouldn't worry about it too much. May well be some kind of conflict with my operating system (and possibly graphics card) and the program.

I just ran your program on a Windows XP laptop and I could not reproduce the font problem. I was surprised though when the window overlap problem on start up was still there.

Wish you the best

[hgm]

Well, indeed I could not reproduce it. Under XP I have quite another problem with the font-based rendering, though: On size "bulky" and below, many of the white pieces are rendered transparant (whole or in part)! On Win2k I don't have any of that, even on size "petite" all white pieces are perfectly white. I guess there must be some difference in the way the OS handles the true-type fonts.

This part of the code is not mine, and I never studied it. But I believe Allessandro uses flood fill to make the region outside the piece transparent. Apparently WinXP renders the fonts (containing the piece outlines) such that the outlines contain holes, through which the flood fill leaks into the piece. I am not sure I could do anything to cure that. For now, I will consider it a deficiency of the font, which apparently needs fatter lines.

This experimenting brought to light an embarrasing bug, though: With font-based rendering, the Archbishop was not displayed (I had changed its internal encoding, and had overlooked to adapt it there). I consider this so bad, that I immediately re-released 4.3.13 with a bugfix to this. (4.3.13b). The new version (differing from 4.3.13a only in correctly displaying the Archbishop) is already on Fonzy's website.

[hgm]

Sorry folks, but another bad bug surfaced. In hunting for the bug in Shatranj promotions on ICS I added some code, which I later deleted (because the problem turned out to be elsewhere). But I forgot to delete an 'else'. The result is now that garbage is appended to the SAN of a promotion move, and some engines (that request to receive the moves in SAN) choke on this. (Not the ones I tested with... )

I fixed the bug, but have not distributed the fixed version (4.3.13c) yet to those hosting it. So better wait downloading it until I tell here that it is safe to download.

[Guerrero]

Well, indeed I could not reproduce it. Under XP I have quite another problem with the font-based rendering, though: On size "bulky" and below, many of the white pieces are rendered transparant (whole or in part)! On Win2k I don't have any of that, even on size "petite" all white pieces are perfectly white. I guess there must be some difference in the way the OS handles the true-type fonts
...
I am not sure I could do anything to cure that. For now, I will consider it a deficiency of the font, which apparently needs fatter lines.
.

Hi Harm.
I did not understand why people mentioned never this problem.
This problem is old. Even I said it to Alessandro but only I had it.
Then I did all Marroqui fonts with fatter lines 2 years ago.

If you wish these fonts I may send them to you.

[hgm]

Actually, it might not be an OS-related problem, but a screen resolution problem. This is difficult for me to test.

I think indeed it should be considered a problme of the font. Problem is that fonts supporting fairy piece symbols (even if onlythese obnoxious rotated versions of normal Chess symbols) are virtually non-existent. I need a font with 2 x 22 piece types. (And just pieces, no light or dark-squares background, as you also often see.)

[hgm]

OK, Fonzy now has 4.3.13c on his website, so you can safely download from there again.

[Sven]

Hi Harm,

many thanks for your great work on WinBoard_F! Here are some smaller issues on your WinBoard_F 4.3.13b release (I guess they will be valid within your brand new 4.3.13c, too):

1) With /debug, WinBoard_F now prints some binary characters into the "winboard.debug" file which causes a little bit of trouble when opening the file with a text editor that switches into some "hex edit" mode in this case ...
At least lines containing "CoordsToAlgebraic" are affected.
In "moves.c", line 1377, the variable 'promoChar' is printed with a '%c' format directive while a few lines above it is set to NULLCHAR (== '\000') in case it comes in with the value 'x'. This might cause the problem described above. One of many possible fixes would be to pass something like "promoChar ? promoChar : ' '" to affected printing code.
There may be more occurrences of this type. I think 4.3.12 did not behave this way.

2) winboard.hlp not found (this was already the case in previous WinBoard_F releases)

3) A general question regarding the WinBoard(_F) project: Do you think it is possible to have a common WinBoard/XBoard code base again that covers, in addition to the current WinBoard_F code:
- all changes to the original WinBoard code that have possibly been made after the last official WinBoard 4.2.7b (probably to be found in the Savannah CVS archive);
- all changes to the WinBoard_X code that have possibly been made by A. Scotti after the point where you took his code as a base for WinBoard_F (are there any?);
- a working build environment for XBoard, based on some common WinBoard/XBoard code as far as possible;
- a working build environment for MS Visual Studio.
I know this may be quite a lot of work, and the priority may be low for you, which I could accept At least one could think about it.

I'm also interested in other opinions regarding item 3.

Sven

[Sven]

1) With /debug, WinBoard_F now prints some binary characters into the "winboard.debug" file

Of course I can apply a filter script, like this one (an ugly hack with very special assumptions about the contents of winboard.debug):

Code: Select all

#!/bin/sh
# wbf_nullchar_filter.sh
#
# Usage, e.g. under cygwin bash:
#
# chmod +x wbf_nullchar_filter.sh
# ./wbf_nullchar_filter.sh < /some_path/winboard.debug > /some_other_path/some_output_file

tr '\0' '@' | sed -e 's/\(CoordsToAlg.*) \)@/\1/' -e 's/\(promochar=0=\)@/\1/'

Fixing the problem would still be nicer, though ...
Sven

[hgm]

1) OK, I guess that the only source of non-printable ASCII codes is the printing of the promoChar. I will fix this in the next release perhaps by throwing out the offending print statements altogether. (It seems that this part is working now.) I made unexpectedly fast progress in implementing features I had in mind for 4.3.14, so I might release that very soon. (CRC works, autoKibitz works, nodes-per-second play seems to work (although I did not really have an engine on which I could test it). I will make sure it has clean debug output.

2) The help-files are a problem, as I don't know how to make help files at all. I furthermore understood that help files are now to be considered obolete, and that from Vista on help will be based on html files. Is there anyone that could help here? (No pun intended.)

3) I think that Allesandro stopped development of WinBoard_x before I started working on WinBoard_F (as he bought a Mac...), so the changes you talk about should include all of WinBoard_x. Problem is that I don't have any computers here that run Linux. I would have to get used to it (I don't even know how to edit files on Linux, for example). Being clumsy at editing and compiling is not ideal for development...

I hardly made any changes to the platform-dependent code contained in winboard.c. Just adding more piece types, and similar more-of-the-same changes that I could make copy-cat fashion without understanding how the graphics routines really work. This included adding a lot of command-line options (the processing of which, for a reason I don't understand, are located in winboard.c rather than in the platform-independent part backend.c). But the latter is rather trivial, and I could easily add the same options to xboard. The main problem is that Allessandro added a lot of graphics stuff to winboard.c, (and opening new windows for engine output etc.) for which I don't understand how it works at all, and it would somehow have to be all ported to xboard. This doesn't only require knowledge of how graphics works on Windows, but also how you can accomplish something similar under Linux.

A few people experienced on Linux have already their hand at this. The last one was Kong Sian, and I suppose he has sort of given up too. The result of their efforts, however, is that there already exists an xboard.c that can be compiled together with the WinBoard_F platform-independent files, and that supports the different board formats and the crazyhouse holdings. (We stopped short of the point where we would have to black out some of the squares between board and holdings.) But it would still require adding opening of the auxilary windows, adding menus, etc. All stuff I know nothing about: basically I don't know anything about windows programming, I am strictly a stdin/stdout person and my knowledge of I/O is limited to fprintf() and fgetc()... So I am not really the ideal person to port for porting change I did not make myself and am mostly unaware of to a platform I hardly know and have no experience in.

Of course if a better suited person would volunteer, I would be willing to offer any assistence I can for porting changes for which I am responsible. e.g. like adding most of the options.