Compiling ChessV 9.2

[Greg Strong]

To convert the project to a console app, you probably want to use the IDE to create a new (empty) console app, copy all the source files to that directory (preserving the folder heirarchy), and add them to the project.

Note #1. You'll need to write a main() function; the start point for the windows GUI apps is WinMain()

Note #2. It builds and runs well with Visual C++ .NET 2003. When I tried to build it with 2005, things didn't work well and the chess engine would crash a lot. It's probably the code, not the compiler - I suspect it's just differences in the code optimization that exposed problems in the code.

Note #3. ChessV doesn't support tournament time controls; only move in x number of seconds.

If you're really determined to go through with this, I will help as much as I can. I also have a newer code base that I can send you (although it only has fairly small improvements.) I can be reached by email at mageofmaple at gmail.

[hgm]

I have written a main() that does nothing but call WinMain:

Code: Select all

char *arg;

int main(int argc, argv)
{
    arg = argv[1];
    WinMain(NULL, NULL, NULL, SW_DEFAULT);
}

I can then compile the whole thing as a console application (by adding /SUBSYSTEM:CONSOLE as extra linker option; I have not figured out how to delete the /SUBSYSTEM:WINDOWS option that was already there, but apparently the conflicting options do not kill the linker, and last one counts, so that is good enough for me). This console application does exactly the same as the old ChessV, but the difference is that stdin and stdout remain open so that I can use printf() and getchar() to communicate with WinBoard.

So for now my approach will be the quick and dirty one, where I leave the ChessV GUI largely intact (it just prints too much interesting info there while thinking, which would be a lot of work to divert to WinBoard). It is quite easy to make it print its move on stdout (in the routine Move() and where it selects a book move), and I am going to make that depenent on the global variable holding a copy of the first command-line argument arg != NULL.

I am now adding an input thread that will process WB commands on stdin. For any moves that will come in it will use the routine DropPiece() that is normally called from MouseButtonRelease(), to simulate a move entered by the mouse.

What I have in mind is specifing the variant (by its interal ChessV name, e.g. "Capablanca Chess") as first command-line argument, rather than react on the WB variant command, so that you can also select variants that WinBoard does not now (e.g. Schoolbook) and play them as a similar variant (e.g. capablanca) with legality testing off.

Forthe time control I will set the maxThinkTime from the WB level command dividing the time through the movesPerSession in a standard TC, and by 80, (and add any increment) in incremental TC. Perhaps in the latter case I can actually divide by 40 in stead and repeat that calculation on every move based on the WB time command, so that ChessV will speed up if the game is long. My principal interest is in standard TC anyway.

I hope to have something that can play automatic games against other WinBoard engines today in a kludgey way; from there we can see how much effort we want to invest to make a smoother product. I always like to get something working as quickly as possible, no matter how primitive, so that it can be gradually improved by trial ad error. The main obstacles on the path I am going will likely be unexpected popups that will stall ChessV in automatic play where they will not be answered, and most of the work will be to track them all down and suppress them, andwering the question they wre asking from info that got in from WinBoard.

[hgm]

I am nearly there: ChessV plays automatically under WinBoard, albeit a bit slow. (It does not seem to respect the maxThinkTime I derive from the WB level command.)

The main problem, however, is that it crashes after some 20 moves. (It once happened after 3 moves, but I cannot reproduce that.) Adding some printouts reveal that it crashes inside the nagamax search. Do you have any idea what could cause that?

What I do to enter the moves is call LiftPiece and DropPiece.

Code: Select all

		&#125; else if&#40;buf&#91;1&#93; <= '9' && buf&#91;3&#93; <= '9' && buf&#91;0&#93; >= 'a' && buf&#91;2&#93; >= 'a') &#123;
			// input move; simulate mouse entry
			int nRanks = theBoard->GetNumberOfRanks&#40;);
			int nFiles = theBoard->GetNumberOfFiles&#40;);
			int from = &#40;buf&#91;1&#93;-'1'+&#40;nRanks>9&#41;)*nFiles + buf&#91;0&#93;-'a';
			int to   = &#40;buf&#91;3&#93;-'1'+&#40;nRanks>9&#41;)*nFiles + buf&#91;2&#93;-'a';
			Piece *piece = theBoard->GetSquareContents&#40; from );
			theBoard->LiftPiece&#40; piece );
			theBoard->DropPiece&#40; to );
			&#58;&#58;InvalidateRect&#40; theWindow, NULL, false );
		&#125;

Could this leave the Board in an inconsistent state because I forget to update something while entering moves? The only difference between normal operation and what I do now is that I skip the variant-selection dialog and set gameSelection to the command-line parameter in stead, and then suppress the dialog in GenericStartGameFunction(), setting the IsComputerControlled variabes only in reaction to the WinBoard new, force and go commands. Ad that I enter moves by the above code.

[hgm]

This game can go into history as the first complete game played by ChessV as a WinBoard engine, but only by virtue of the fact that it was so short that ChessV did not have the time to crash. I guess I am playing a debug version here that does all kind of run-time checks, and thus is very slow. I must still learn how to build a real version.

Code: Select all

[Event "Computer Chess Game"]
[Site "CHESS_LAPTOP"]
[Date "2009.09.23"]
[Round "-"]
[White "ChessV"]
[Black "Fairy-Max 4.8L"]
[Result "0-1"]
[TimeControl "40/300"]
[Variant "capablanca"]
[Annotator "1... +0.13"]

1. Nh3 Nh6 {+0.13/7 23} 2. Nc3 c5 {+0.15/7 10} 3. f4 d6 {+0.09/7 4} 4. Bf2
Nc6 {+0.09/6 5} 5. e4 Ng4 {+0.02/6 3} 6. Bxg4 Axg4 {+0.39/7 5} 7. Ab3 e5
{+0.46/6 7} 8. Nd5 exf4 {+1.09/5 3} 9. Rc1 Ci6 {+1.35/5 4} 10. i3 Ci4
{+1.79/6 7} 11. Kg1 f3 {+1.54/5 5} 12. j3 Ch6 {+2.17/6 9} 13. Be3 Cxh3+
{+8.81/6 6} 14. Kf1 fxg2+ {+79.95/7 3} 15. Kxg2 Qxe4+ {+79.96/8 5} 16. Kf1
Axh2+ {+79.97/10 3} 17. Ke2 Qg4+ {+79.98/28} 18. Kd3 Ae5# {+79.99/28}
{Xboard adjudication: Checkmate} 0-1

[hgm]

Some more info:

The crashes seem to occur always in the routine SearchRoot(), when it is doing a re-search after a fail high.

In case anyone wants to have a try at this: I posted the ChessV-9.2WB executable plus the three source files I modified on my website as:

http://home.hccnet.nl/h.g.muller/ChessV.zip

[Eelco de Groot]

I have only ever used MSVC 2005 in the graphical user interface but there you can choose at the top in the toolbar after a green arrow between 'Debug' which is probably your default and 'Release' which creates a version not using the Asserts etc. In the commandline you probably have 'Debug' somewhere. This is what I use for Stockfish without any real optimizations, maybe some of these you could try Harm to get a faster compile:

Code: Select all

/O2 /Ot /GT /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Fo"Release\\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt

If I change to a debugging version the command line parameters become:

Code: Select all

/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Wp64 /ZI /TP /errorReport:prompt

[Eelco de Groot]

I have only ever used MSVC 2005 in the graphical user interface but there you can choose at the top in the toolbar after a green arrow between 'Debug' which is probably your default and 'Release' which creates a version not using the Asserts etc. In the commandline you probably have 'Debug' somewhere. This is what I use for Stockfish without any real optimizations, maybe some of these you could try Harm to get a faster compile:

Code: Select all

/O2 /Ot /GT /GL /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Fo"Release\" /Fd"Release\vc80.pdb" /W3 /nologo /c /Wp64 /Zi /TP /errorReport:prompt

If I change to a debugging version the command line parameters become:

Code: Select all

/Od /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\" /Fd"Debug\vc80.pdb" /W3 /nologo /c /Wp64 /ZI /TP /errorReport:prompt

I should add that with these parameters you get a small .exe that however can't be used on all systems.

Teemu Pudas pointed out to me in the CCRL forum that you need to add a /MT switch that unfortunately also increases the size of the executable a lot:

I think it is caused because I compiled it with MSVC 2005 and I can find some other posts that this sometimes happens. The compiled program I think can't find certain DLLs on your PC that are actually present in most cases, but you would have to look them up.

It's because MSVC's default is to link the CRT dynamically. Add /MT to the command line or a link to the Visual C++ 2005 redistributable package (a ~2.5MB download) in the readme.

Yes, Vempelle is right. In most cases, you just need the updated Microsoft Visual C++ 2005 Redistributable Package (x86) and for x64 as well if you use it.

Eelco

[hgm]

Hmm, when I switch to "release" I get 49 compilation errors. So I guess I will leave that for the experts.

I discovered that the crashes seem to be more frequent at short TC; I was playing 40/4 which should be 6 sec/move (where ChessV was always on the way to forfeiting; I now calculate its time per move 60% f what it ought to be, and then it barely manages to make the first time control).

At 40/15 I had no crasha at all, though:

Code: Select all

[Event "Computer Chess Game"]
[Site "CHESS_LAPTOP"]
[Date "2009.09.23"]
[Round "-"]
[White "ChessV"]
[Black "Fairy-Max 4.8L"]
[Result "0-1"]
[TimeControl "40/900"]
[Variant "capablanca"]
[Annotator "1... +0.16"]

1. Nh3 Nc6 {+0.16/8 31} 2. Nc3 e5 {+0.17/7 10} 3. f4 b6 {+0.06/6 12} 4. Bf2
Nh6 {+0.07/7 26} 5. e3 Aa6+ {-0.02/6 11} 6. Be2 Ab4 {+0.03/7 20} 7. Ab3 f5
{+0.12/8 49} 8. Aa4 Bf6 {+0.14/7 33} 9. a3 Ae7 {+0.03/7 20} 10. Ab5 Qd8
{+0.02/6 10} 11. Rc1 a6 {+1.52/9 11} 12. Ad3 e4 {+2.46/10 16} 13. Nxe4 fxe4
{+2.71/10 23} 14. Axe4 Bxb2 {+2.94/9 19} 15. Rb1 Bd5 {+3.07/7 17} 16. Axd5
Axd5 {+3.48/9 10} 17. Rxb2 Ng4 {+3.46/8 10} 18. e4 Axe4 {+3.79/8 9} 19. Bh4
Nf6 {+3.98/8 16} 20. Bg5 h6 {+4.40/9 25} 21. Bf3 Ad6 {+4.90/8 9} 22. Bxf6
gxf6 {+4.82/9 57} 23. Rb3 Nd4 {+5.04/10 20} 24. Bxa8 Nxb3 {+5.35/9 8} 25.
Bd5 Ab5+ {+5.69/10 32} 26. d3 Nd4 {+5.65/10 44} 27. a4 Axa4 {+5.80/10 14}
28. c3 Nf5 {+5.79/9 14} 29. Be4 Nd6 {+5.77/10 18} 30. Bf3 Ac2 {+5.88/9 14}
31. Qe2 Ab1 {+5.81/9 20} 32. c4 Ac3 {+5.79/9 13} 33. Qf2 b5 {+5.82/9 32}
34. Qc2 Ad4 {+6.94/10 11} 35. Qd2 bxc4 {+7.11/10 32} 36. dxc4 Nf5
{+7.05/10 22} 37. Qd3 Ae3+ {+7.74/9 9} 38. Ke2 Qe7 {+7.70/9 40} 39. Qe4
Axc4+ {+12.08/8 6} 40. Kf2 Qc5+ {+12.28/9 11} 41. Ke1 Aa5+ {+12.28/9 15}
42. Ke2 Ac3+ {+12.29/9 10} 43. Kd3 d5 {+15.66/7 16} 44. Qxd5 Ab5+
{+79.96/12 11} 45. Qc4 Qxc4+ {+79.97/28 1.6} 46. Kd2 Qc3+ {+79.98/28} 47.
Kd1 Ne3# {+79.99/28}
{Xboard adjudication: Checkmate} 0-1

So the crashes might be related to getting a timeout during a low iteration with no move found yet.

[hgm]

I continue to get some very weird behavior in ChessV, and it is hard to believe that this is my doing, as it seems to occur in code that I have not touched at all. I put a debug print in the loop over moves in SearchRoot, to get a better idea when the crashes occur. But now I obsereved a very weard behavior: In the position

[d] r4kb2r/1ppq1ppppp/p2p4c1/4p5/4P2Pn1/2NAB5/PPPP1Q2PP/2R4R1K w kq - 3 23

where ChessV is white, it suddenly switches to searching for the opposite color! A snippet from the debug file:

Code: Select all

732283 <first &#58; # move 15-65 @ 0
732283 <first &#58; # move 15-26 @ 0
732283 <first &#58; # done 1
732283 <first &#58; # iteration 1 completed
732283 <first &#58; # rootSearch 2
732283 <first &#58; # move 2-5 @ 1
732283 <first &#58; # move 7-5 @ 1
732283 <first &#58; # move 22-43 @ 1
732283 <first &#58; # move 2-4 @ 1
732283 <first &#58; # move 15-25 @ 1
732283 <first &#58; # move 7-4 @ 1
732283 <first &#58; # move 23-14 @ 1
732293 <first &#58; # move 37-47 @ 1
732293 <first &#58; # done 2
732293 <first &#58; # fail-hi reSearch 2
732293 <first &#58; # move 2-5 @ 1
732303 <first &#58; # done 2
732303 <first &#58; # iteration 2 completed
732303 <first &#58; # rootSearch 3
732303 <first &#58; # move 75-72 @ 2
732313 <first &#58; # move 70-74 @ 2
732323 <first &#58; # move 70-72 @ 2
732333 <first &#58; # move 79-77 @ 2
732343 <first &#58; # move 38-57 @ 2

White re-searches the move 2-5 (Rc1-f1, a white move) at 2 ply, apparently seems to solve the fail high to its satisfaction (which is a bit strange after searching only one move?), and then starts iteration 3 by searching 75-72 (O-O-O for black!).

Btw, I have managed to build a Release version now, which indeed searches 2-3 ply deeper than the debug version, and seems to stick to time better. The compile errors I had before suddenly all went away. No idea why...

[smrf]

ChessV sometimes seems to switch colors when under pressure. I reported that repeatedly to its author. Maybe because of an errornous undo of moves, when potential mates will occur. But ChessV's author did not provide any corrected version since then, thus I stopped any testing of SMIRF vs. ChessV. Moreover the SMIRF project is sleeping ...