Author: Russell Reagan
Date: 16:30:56 08/21/02
Go up one level in this thread
On August 21, 2002 at 18:33:36, Dann Corbit wrote:
>I think an unambiguous, complete, standardized and improved protocol would be a
>great benefit. Whether this occurs as an upgrade to Winboard, or an upgrade to
>UCI, or as a new protocol it would be nice if it could happen. Probably, an
>upgrade to Winboard would be best. Especially if it had a backwards
>compatibility mode. However, I think the directions that are interesting to me
>are not interesting to Tim Mann (EGTB support, Hashing support, Tournament
>support, EPD support, etc.).
Tim Mann has said that he's tired of working on the project. Winboard is open
source. Perhaps someone could take the project off Tim Mann's hands? Or start a
new protocol using the open source Winboard as a starting guide. UCI wouldn't
provide much other than ideas since it's not open source. Of course, taking over
Tim's project doesn't mean he can't give his input and guidance. My feeling that
I got from his word was that he simply doesn't have time to do the work. There
are plenty of people who understand what's important and what's needed, to
develop a good protocol that will (hopefully) solve everyone's needs.
>I am not sure how you can communicate to Winboard how these other commands
>should be executed. Since they are internal, how will Winboard benefit?
>
>Maybe your idea could be used to {for instance} access EGTB tables, but how will
>Winboard know that is what it is for and also how the other program can benefit?
>
>Maybe a replaceable driver idea is what you are getting at (e.g. Don't use your
>function Egtb_Lookup(board_pos), but instead use mine
>Egtb_Lookup_Custom(board_pos) so we can supply our own callbacks if we would
>prefer. Or we might supply a null function if we mean to say "I'll use my own
>EGTB lookup thank you!")
I think my view of GUI is different than yours (maybe). I would love to see a
GUI where the developer can test certain things. For example, I'd like to be
able to customize the GUI, perhaps use my own piece graphics, etc. Another thing
I'd like to see in a GUI is a feature where you could change the colors of
squares (not just light/dark). For example, if you wanted to visually display
square control, you could have uncontrolled squares be (say) blue, then use a
gradient from (say) white to black, and a square that is controlled by black by
far (attacked by black maybe 4 times, 0 by white) would be totally black, and
various degrees of gray in between. I would like to be able to display bitboards
graphically, see attacks, visually "see" king safety by perhaps highlighting
vulnerable squares to various degrees, etc. I think Winboard has classically
been a communicator between an engine and another engine or user, and it updates
the user to the current status of the game. I would almost classify it as a
"communicator" rather than "GUI".
Basically I think the purpose the GUI should do a few things:
-Allow the engine to play humans, engines, and on internet chess servers
-Allow a customizable GUI environment, where the engine author can create his
own menu commands, customize the graphics, which allows for a nicer experience
for the user, and also for debugging for the author.
Basically I think it should be both communicator and graphical user interface.
The package would come with a "stock" GUI, and then you could customize it as
you saw fit, and it would still support the basic commands needed for playing
humans, other engines, and on ICS's.
What do you think? Good ideas or not?
Russell
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.