[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] Hi from a new member of the xboard team

From: h.g. muller
Subject: Re: [XBoard-devel] Hi from a new member of the xboard team
Date: Tue, 20 Dec 2011 23:24:15 +0100

1*2*3*4 + 5*(6*7*8*9 + 1*2)

That is a bad example as no compiler that I can imagine would suggest more parentheses in the latter expression.

Well,replace * by && and + by || and it will complain all the time...

Interesting. I am not sure that it would be a good idea to give more tasks to the game engines. It would make it harder to make engines, and make the engines less portable to other interface programs as the distinction between gui and engine would be weakened.

But I also agree that it is a problem that xboard have to know the rules of many different games. Already now all this knowledge about many chess variants complicates the code too much, I think.

Indeed, much of what you say is true. But this is mainly meant for games where just a hand full, or perhaps even only a single engine exists. Now people programming such a game typically have to program the entire GUI with it, including the graphical part, or use text interfaces. For them it would be a huge simplification if they can control a fully graphical GUI through the text interface of the protocol.

I would consider taking specific game knowledge out of xboard, and instead make a plugin-structure, so a module for the actual game can be loaded at run time. That would in some ways simplify the core code, and make it possible for everyone to write plugins for any game - much in the same way as everyone can now build their own engines if they wish to do so and have the necessary programming skills.
Using plug-ins is a good idea. But a plug-in would duplicate many functions of the engine, as the latter would definitely have to be able to do move-legality checking or generate lists of moves. In fact what we now call engine initially was nothing but a plug-in responsible for maintaining the game rules, and XBoard still uses the first engine as such (keeping it in sync in EditGame mode, for instance). So I think this idea would eventually pan out to using a 'referee engine' for the plug-in, which would just be a normal engine that fully implements the new protocol features (which in principle are optional, controlled by 'feature highlight=1'), so that other engines don't have to bother with that.

The advntage would be that the person writing the first engine for a game would not have to code a eparate plug-in, but could draw on the engine for that.

I can confirm from own experience with xboard 4.6 on Linux that it is somewhat slow to start up. I can do some profiling to see what is taking the time.

In the case I ws referring to this was a 12-20 sec delay during which the main window stayed blank, and we were able to trace it to calls to the X-server. There is already a lot of e-mail correspondence about this, but I am not sure it is visible in a public place...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]