
Damage GUI
-
- Posts: 1368
- Joined: Thu Jun 20, 2013 17:16
- Real name: Krzysztof Grzelak
Re: Damage GUI
I'm sorry that I asked Bert. Can you share a file so that testing the option "DataBase" in Damage GUI.
Re: Damage GUI
The Database is basically an unsupported function in the Damage GUI.
I mainly used it for my own purpose.
I also did not test it recently, so it might not even work these days.....
Basically I started the option as an alternative for TurboDambase, and the code base I already developed is really huge.
The input file is a TurboDambase (TDB) file (like mega2005.cgd).
And you understand that Im not able to share this (Im a legal copy owner of the TDB).
Next to that, I understand much of the internals of the .cgd file, so Im able to write code for it.
But as you know, (for maybe good reasons) Klaas want to keep the format proprietary.
There are certain things in the .cgd file I still do not fully understand, so therefore I stoppped with further implementation.
But maybe I will restart some day.
Bert
I mainly used it for my own purpose.
I also did not test it recently, so it might not even work these days.....
Basically I started the option as an alternative for TurboDambase, and the code base I already developed is really huge.
The input file is a TurboDambase (TDB) file (like mega2005.cgd).
And you understand that Im not able to share this (Im a legal copy owner of the TDB).
Next to that, I understand much of the internals of the .cgd file, so Im able to write code for it.
But as you know, (for maybe good reasons) Klaas want to keep the format proprietary.
There are certain things in the .cgd file I still do not fully understand, so therefore I stoppped with further implementation.
But maybe I will restart some day.
Bert
Re: Damage GUI
Some background information related to the Database function in the Damage GUI, can be found in the thread Search Algorithm, page 15, and onwards.
Apparently I worked on this around October 2013 (
)
Bert
Apparently I worked on this around October 2013 (

Bert
-
- Posts: 1368
- Joined: Thu Jun 20, 2013 17:16
- Real name: Krzysztof Grzelak
Re: Damage GUI
Thank you Bert for your answer. Please, you are Bert answer the following question. Please write or option (one of my favorites) "tournament" will work and what draughts engines today can take part in the tournament.
Re: Damage GUI
The Tournament Option is also one of my favourites.
It is designed to fully automatically run a tournament, without operator involvement.
More or less based upon the (non exisiting) Hub protocol.
There are officially no engines with this protocol so far, so I also cant test it.
Thats also on of the reasons I started with Dwarf, to have a very simple engine which can play according Hub, and to show others (as the sources will be shared), how to easily implement this.
I already did this for Scan.
Dwarf will be able (quite soon) to play games (although most will be lost, as it has a demonstration purpose, and is not equipped with an evaluation).
Also the program of Joost will include the Hub interface. But as Joost uses state of the art Intel processor instructions, it can only run on the newest processors, and I dont have information, if Joost will open-source his program.
Im also able to inject Hub into Moby Dam, as Harm has shared sources.
And last but not least it might be possible to write a DXP - Hub converter, as Ed and I did for Truus and Flits.
Bert
It is designed to fully automatically run a tournament, without operator involvement.
More or less based upon the (non exisiting) Hub protocol.
There are officially no engines with this protocol so far, so I also cant test it.
Thats also on of the reasons I started with Dwarf, to have a very simple engine which can play according Hub, and to show others (as the sources will be shared), how to easily implement this.
I already did this for Scan.
Dwarf will be able (quite soon) to play games (although most will be lost, as it has a demonstration purpose, and is not equipped with an evaluation).
Also the program of Joost will include the Hub interface. But as Joost uses state of the art Intel processor instructions, it can only run on the newest processors, and I dont have information, if Joost will open-source his program.
Im also able to inject Hub into Moby Dam, as Harm has shared sources.
And last but not least it might be possible to write a DXP - Hub converter, as Ed and I did for Truus and Flits.
Bert
-
- Posts: 474
- Joined: Wed May 04, 2016 11:45
- Real name: Joost Buijs
Re: Damage GUI
As you already noticed I made several changes to get the program running on older processors as well.BertTuyt wrote:
Also the program of Joost will include the Hub interface. But as Joost uses state of the art Intel processor instructions, it can only run on the newest processors, and I dont have information, if Joost will open-source his program.
Bert
Instead of packing the whole move in 44 bit, I now pack it in a more conventional way to 48 bit and I removed the BMI2 instructions from the magics initialization routine, I had to make some changes to the hash-entry format to support the larger move field but everything still fits.
The only thing that still uses BMI2 is the index calculation for the pattern evaluation, I will add a second index routine that does it the conventional way, this is not difficult but it will be (a lot?) slower, this is the price you have to pay for running on old CPU.
This morning I also replaced the Windows threads and locks with C++11 counterparts, I had a few difficulties because the C++11 stuff behaves somewhat differently but after some debugging I got it working fine.
Next I will add the HUB protocol, time-controls and pondering to make the program actually play a game, refinements to the search and the evaluation function will come later.
-
- Posts: 474
- Joined: Wed May 04, 2016 11:45
- Real name: Joost Buijs
Re: Damage GUI
Bert,
In the hub protocol when you send a move to the GUI you also send all the square-numbers on which you captured a piece, I assume that the GUI is not smart and that these squares have to be in the right order, or is this not needed?
The point is that in my engine the captured-squares are just a bit-board and that I don't know the order of these captures, I can only circumvent this by adding a second move-generator that keeps an ordered list of capture-squares per move.
Joost
Edit:
By looking at the modified Scan source you sent me, I notice that you don't retain the order there as well, do you use these squares only to distinguish between two captures with equal from-to squares? When you want to show a move to the user (in the engine-window or a move-list) I guess that these squares have to be ordered or does you GUI take care of this?
Right now I will do it the easy way, just sending these squares unordered, when this is not sufficient I will change it later on.
In the hub protocol when you send a move to the GUI you also send all the square-numbers on which you captured a piece, I assume that the GUI is not smart and that these squares have to be in the right order, or is this not needed?
The point is that in my engine the captured-squares are just a bit-board and that I don't know the order of these captures, I can only circumvent this by adding a second move-generator that keeps an ordered list of capture-squares per move.
Joost
Edit:
By looking at the modified Scan source you sent me, I notice that you don't retain the order there as well, do you use these squares only to distinguish between two captures with equal from-to squares? When you want to show a move to the user (in the engine-window or a move-list) I guess that these squares have to be ordered or does you GUI take care of this?
Right now I will do it the easy way, just sending these squares unordered, when this is not sufficient I will change it later on.
Re: Damage GUI
Joost, for a capture move, the move order is not important.
The base reason for the move format is to have all information to create the new board posiiton from the move info (although the GUI has an own MoveGenerator).
Bert
The base reason for the move format is to have all information to create the new board posiiton from the move info (although the GUI has an own MoveGenerator).
Bert
Re: Damage GUI
BertTuyt wrote:Herewith the Dwarf Sources:
https://www.dropbox.com/sh/uv2d2kauvjyg ... 7x1La?dl=0
Here only the Hub commands pos, depth and go are implemented.
Here the folder with the GUI , just start the GUI and Dwarf will be activated.
To play a match against Dwarf (example Dwarf plays black, Oppponents Player-Engine), Levels Fixed Depth (example 12 or whatever), and you just start...
https://www.dropbox.com/sh/4f0fk89rwqrk ... auoea?dl=0
Any questions, comments welcomed.
Bert
Hello Bert
It is a pleasure to play with Horizon 46 and Damage2016.
I look forward to see Dwarf play as well or better with its database.
Yves
Re: Damage GUI
The version of the Damage GUI came from one of your dropbox links:
https://www.dropbox.com/sh/u1nekyp94kjz ... bZbka?dl=0
Hi Bert
I tested this version of Dwarf but it stops
From 16 and 21 moves in play alone and in dxp.
Thank you for seeing the problem.
Yves
https://www.dropbox.com/sh/u1nekyp94kjz ... bZbka?dl=0
Hi Bert
I tested this version of Dwarf but it stops
From 16 and 21 moves in play alone and in dxp.
Thank you for seeing the problem.
Yves

Re: Damage GUI
In a previous post I shared that I wont do much this year (2017) on Engine development.
This doesn't mean I completely stopped with Computer Draughts.
In the (few) free hours I still wok on the Damage GUI.
I'm currently busy (again with extreme slow progress, so don't expect white smoke soon) on a tournament manager.
The protocol I use is the non-defined fuzzy Hub-ish.
Next to that I included an arbiter, who can decide (if you want so) to adjudicate endgames, based upon the databases of Ed.
Basically the arbiter is a third engine (which is also activated during tournament start) optimized for this purpose, so no search routines and alike.
It initializes the DB, reads some index files, and waits for a position to examine.
So it only checks if the position is in the database, and reports a DB result (if any).
This also means that the arbiter requires hardly a cache for this purpose (as the only request is done at the root, and not during search).
I want to use these options to study some questions related to search strength, evaluation functions, and diminishing returns.
Will keep you posted, at irregular intervals...
Bert
This doesn't mean I completely stopped with Computer Draughts.
In the (few) free hours I still wok on the Damage GUI.
I'm currently busy (again with extreme slow progress, so don't expect white smoke soon) on a tournament manager.
The protocol I use is the non-defined fuzzy Hub-ish.
Next to that I included an arbiter, who can decide (if you want so) to adjudicate endgames, based upon the databases of Ed.
Basically the arbiter is a third engine (which is also activated during tournament start) optimized for this purpose, so no search routines and alike.
It initializes the DB, reads some index files, and waits for a position to examine.
So it only checks if the position is in the database, and reports a DB result (if any).
This also means that the arbiter requires hardly a cache for this purpose (as the only request is done at the root, and not during search).
I want to use these options to study some questions related to search strength, evaluation functions, and diminishing returns.
Will keep you posted, at irregular intervals...
Bert
Re: Damage GUI
I'm now able to play a tournament between 2 engines, with the Damage GUI.
Basically the architecture is able to deal with 16 engines, but I did not test this so far.
See below screen shot of the work in progress.
The 2 Engines Scan20 and Scan21 are identical, and use a rubbish Hub-ish protocol
.
The Tournament in this case is 1 round, 1 pairing every round, and games are played based upon 2-move-ballot FEN file.
In this case no alternate color, so Scan20 always plays with white.
One can set the tournament in such a mode, that every FEN position is played X times, and with alternate colors.
In the screenshot you can see actual tournament progress.
So work in progress, and keep you posted....
Bert
Basically the architecture is able to deal with 16 engines, but I did not test this so far.
See below screen shot of the work in progress.
The 2 Engines Scan20 and Scan21 are identical, and use a rubbish Hub-ish protocol

The Tournament in this case is 1 round, 1 pairing every round, and games are played based upon 2-move-ballot FEN file.
In this case no alternate color, so Scan20 always plays with white.
One can set the tournament in such a mode, that every FEN position is played X times, and with alternate colors.
In the screenshot you can see actual tournament progress.
So work in progress, and keep you posted....
Bert
- Attachments
-
- Test.PNG (30 KiB) Viewed 10523 times
Re: Damage GUI
Another test.
This time with 3 engines.
And every game-round each engine plays 2 games with opposite colors.
All draws.......
See screenshot.
Bert
This time with 3 engines.
And every game-round each engine plays 2 games with opposite colors.
All draws.......
See screenshot.
Bert
- Attachments
-
- Test 2.PNG (28.09 KiB) Viewed 10452 times
Re: Damage GUI
[quote="BertTuyt"]I'm now able to play a tournament between 2 engines, with the Damage GUI.
Basically the architecture is able to deal with 16 engines, but I did not test this so far.
See below screen shot of the work in progress.
Hello Bert
Very interesting this tournament concept to see playing engines with Damage interface.
It would be great to have a tournament with other engines, if the authors agree.
Sincerely Yves,
Basically the architecture is able to deal with 16 engines, but I did not test this so far.
See below screen shot of the work in progress.
Hello Bert
Very interesting this tournament concept to see playing engines with Damage interface.

It would be great to have a tournament with other engines, if the authors agree.

Sincerely Yves,
Re: Damage GUI
Yves, it would be indeed great if some other programmers implement the (rubbish) hub-ish protocol.
I recognize that the protocol is far from ready (or even ill defined, or non-defined), and therefore some could be hesitant to implement something which is work in progress.
On the other hand it is relatively simple, as I demonstrated for Argus and Scan.
And for Krzystof this would really make Tournaments , very straightforward.
The disadvantage, older programs don't have a hub-interface, so the number of participants are quite limited.
The good news, at least for Truus I guess it is possible to write a Hub-interface, as Ed and I have done for the DXP protocol.
For Flits it might be more tricky (but need to think about this).
When I restart with Engine programming (Damage Engine) in 2018, I will certainly also implement Hub.
As Moby Dam is also console based (so without GUI), here it should be also straightforward.
Basically I already started with that, but (temporary) stopped, to work (and debug) the Tournament Manager (TM).
For Dragon and Kingsrow , if they would go for a console implementation, it might be somewhat more work.
Although based on the available sources (like Scan), it is not rocket science to implement it also here.
I'm now debugging the TM, to deal with all kinds of corner cases.
I have now modified the Scan Engine, so during start the .ini file contains also the search depth (-1 if the search is time controlled, +X for a fixed depth search).
The .ini file also contains the name of the Engine, so I can store copies of Scan in different locations, with different behavior for the TM.
I'm planning to play several 2-move ballot matches (via the TM), with different fixed depth settings, to learn how it influences program strength.
I started with Scan 12 Ply fixed against Scan 20 Ply fixed.
No specific reason for these 2 values, I also want to see if the TM is robust.
And also I slightly change the ET Info Dialog, as you can see in the previous (and forthcoming) screenshots.
Keep you posted,
Bert
I recognize that the protocol is far from ready (or even ill defined, or non-defined), and therefore some could be hesitant to implement something which is work in progress.
On the other hand it is relatively simple, as I demonstrated for Argus and Scan.
And for Krzystof this would really make Tournaments , very straightforward.
The disadvantage, older programs don't have a hub-interface, so the number of participants are quite limited.
The good news, at least for Truus I guess it is possible to write a Hub-interface, as Ed and I have done for the DXP protocol.
For Flits it might be more tricky (but need to think about this).
When I restart with Engine programming (Damage Engine) in 2018, I will certainly also implement Hub.
As Moby Dam is also console based (so without GUI), here it should be also straightforward.
Basically I already started with that, but (temporary) stopped, to work (and debug) the Tournament Manager (TM).
For Dragon and Kingsrow , if they would go for a console implementation, it might be somewhat more work.
Although based on the available sources (like Scan), it is not rocket science to implement it also here.
I'm now debugging the TM, to deal with all kinds of corner cases.
I have now modified the Scan Engine, so during start the .ini file contains also the search depth (-1 if the search is time controlled, +X for a fixed depth search).
The .ini file also contains the name of the Engine, so I can store copies of Scan in different locations, with different behavior for the TM.
I'm planning to play several 2-move ballot matches (via the TM), with different fixed depth settings, to learn how it influences program strength.
I started with Scan 12 Ply fixed against Scan 20 Ply fixed.
No specific reason for these 2 values, I also want to see if the TM is robust.
And also I slightly change the ET Info Dialog, as you can see in the previous (and forthcoming) screenshots.
Keep you posted,
Bert