programming engine, programming GUI

[Stan Arts]

Hello,

there's no reason for the never ending loop, fe. if you have an iterative engine, (Repeat..Until) it's good practise to write it in such a way it's completely interruptable and continuable. Saving all search tree information and status, so you can do something else, for example update the GUI, and continue search.

This is how my (Pascal/Delphi) gui+engine combination works. I don't use threads, but after a multitude of some 1000 searchtree-iterations/nodes I interrupt search, update the gui, draw a new screenframe (neurosis3D is a full screen software rendering application) And continue searching. But this is hardcoding the chess-engine into the gui. Threads would be more elegant, but (or atleast this was so with 1cpu systems) you probably have less control of how much % cpu you want to give to engine or gui, where I can determine this exactly.
Downside is you'd have to compile a gui version and WB/UCI version, but if you write your engine in Unit (Pascal) form, it's easy to do both.

Greets,
Stan

[EricLang]

It's not necessary to hardcode the gui into the engine. You could just call some callback procedure which is implemented by the GUI.
In this way the engine and GUI are strictly seperated.
I'm currenlty thinking of using that instead of threads. I burn my fingers each time with threads.

[EricLang]

@Steve: Thanks I'll have a look at the JVCL component. And Delfi too.

[Daniel Mehrmann]

Here I don't agree. To me, the Winboard protocol looks much more difficult to implement. The Winboard protocol leaves too many things unspecified, like the sign of the evaluation and the format of the PVs. Even something as basic as writing a program that successfully parses the PVs of all available Winboard/XBoard chess engines seems extremely hard.

Well, i know both protcols and worked on the development of both. Ok, in UCI is was just a tiny part. However, i must say it's a question of taste from the engine programmer view. Both protocols are not really comparly to each other if you understand them 100%. The basic ideas behind of them are completly different.

From the commercial view UCI has some buildin options which will be needed for sells stuff. Wb missed that just for one reason: History based. It's older and was born at a time there was no real commercial engines for personal computers like today. At the beginning it wasn't planned as a real protocol. The main task was to find a way to communicate xboard with crafty. That's the reason why you'll find a lot of crafty handling lines in the backend code of X-/Winboard.

However, as i wote it's a question of taste. So, if Tord says its more difficult for him, it's ok. If hgm says he prefers wb its ok.



Best,
Daniel

[Dann Corbit]

Here I don't agree. To me, the Winboard protocol looks much more difficult to implement. The Winboard protocol leaves too many things unspecified, like the sign of the evaluation and the format of the PVs. Even something as basic as writing a program that successfully parses the PVs of all available Winboard/XBoard chess engines seems extremely hard.

Well, i know both protcols and worked on the development of both. Ok, in UCI is was just a tiny part. However, i must say it's a question of taste from the engine programmer view. Both protocols are not really comparly to each other if you understand them 100%. The basic ideas behind of them are completly different.

From the commercial view UCI has some buildin options which will be needed for sells stuff. Wb missed that just for one reason: History based. It's older and was born at a time there was no real commercial engines for personal computers like today. At the beginning it wasn't planned as a real protocol. The main task was to find a way to communicate xboard with crafty. That's the reason why you'll find a lot of crafty handling lines in the backend code of X-/Winboard.

However, as i wote it's a question of taste. So, if Tord says its more difficult for him, it's ok. If hgm says he prefers wb its ok.



Best,
Daniel

Xboard was designed for GnuChess. Crafty came along later.

[trojanfoe]

When programming under MS Windows it's quite common for multiple threads to be used; one is simply sitting in the "main message loop" and processing messages as they appear and the other thread(s) is doing the "work" - I think a combined chess GUI/engine would fit into this category. If you don't use multiple threads you will find the GUI unresponsive to user interaction, for example resizing the window or loading a file. It doesn't matter if you only have one CPU as you cannot guarentee how much CPU time a thread will be given anyway - you can only influence the decision by setting its priority.

I don't know how object-oriented Delphi is but I would always take the approach of having the chess engine logic encapsulated within objects which use some sort of queueing mechanism for input/output - they should be given work to do and return the state of that work using datatypes which are independant of the component which is using them. If you use this approach then you are able to "house" your chess engine in whatever environment suites you - for example built into your combined GUI or as a separate executable (i.e. UCI/Winboard program). You might decide to port your program to Windows CE for example and discover that you cannot spawn a separate UCI process and therefore a combined program is the only solution.

HTH,
Andy

[Daniel Mehrmann]

Xboard was designed for GnuChess. Crafty came along later.

Nope, first comes Crafty, later Gnuchess

[Zach Wegner]

http://tim-mann.org/xboard/engine-intf.html#4

"Originally, xboard was just trying to talk to the existing command-line interface of GNU Chess 3.1+ and 4"

[Daniel Mehrmann]

http://tim-mann.org/xboard/engine-intf.html#4

"Originally, xboard was just trying to talk to the existing command-line interface of GNU Chess 3.1+ and 4"

Nope, i don't say there was a big time differ which engines comes first. My informations based on personal talks with Tim and the first first xboard developer (can't remember the name).

[Zach Wegner]

I'm not sure what you're saying, but the first versions of xboard were made before Crafty even existed. Here's some more: http://tim-mann.org/interview.html

"Originally, xboard and WinBoard were simply graphical user interfaces for GNU Chess, then for GNU Chess and Internet chess servers."

"Some time in 1991, I wanted to play a game of chess, so I went looking on the Internet for free chess software. I found GNU Chess 4.0, which was then under active development by a team coordinated by Stuart Cracraft, and a graphical interface for it called xboard 1.2 that had just been written by Chris and Dan Sears."

Crafty started development after the 1994 ACM tournament, according to Bob.