Pascal Georges schrieb: Hi!
>> Would be an idea, though this will require interaction >> with the keyboard/mouse. Do you have an idea of >> alternative input? Ideally one could just do everything >> from the board, but I think this will not be possible. > > > Novag Citrine uses tricks like "lift briefly your king" to > make engine thinks, but this is a bad idea as when playing > on internet and if I mistakenly touches the king, the > citrine's engine starts thinking and plays for me ! Well, at least for the DGT this is not an issue as there is no engine that starts to do something. ;) In any case the Input Engine throws just an event which has to be interpreted. Now, "lift your king" is the event that is used for triggering a "move now"-event. Currently, in Scid I'd like to pass on this event to the opponent engine, but I could do something like "if mode == analysis then leave_variation". Actually, other moves as with the king are hardly possible to trigger anything as the king is in fact the only piece that is always on the board, except in setup mode. This limits choices for triggers received from the board. > This happened once on FICS and "I" played a poor move :-( See this problem. :( But actually its N/A for the DGT as well as Input Engine protocol. (Thought one would have to stop the Citrine from moving pieces in case one implements Citrine support as input engine. I guess some "stop - take back" would be required here.) > So such thing like "lift your queen briefly" to leave a > variation may be unreliable. As actually no queen has to be on the board it is just not a general solution :) Reliability, though would not be the issue in the point in question as stated above. >> A technical point is: regardless where I am in scid, I never >> know it. Sounds funny, but theres no much status code or >> general backend somewhere. Actually, through the realisation >> of CC code I now understand a bit better how it works >> internally. Maybe I could come up with some solutions here. > > I don't understand. If you mean you don't know wether you > are in a variation and at what level you have all > information from sc_var API. I extended it one day as > indeed info was lacking but I don't think this is still > the case. Ok, I correct me in this point :) Thanks for the addition there. But another point, we already discussed is "how to send moves to the opponent engine". As far as I understood you back then currently there is no real back end where I could say: "tell me the last engines move" or "send this to the opponent engine". I think I'll have to work arrount this by sc_pos or something like that though direct communictation to the opponent engine is not possible. At least consistency checks (necessary between the board and scids representation) are currently done by just fetching the FEN. >> I perfectly agree with Pascal that it would be great to >> have support for this board especially on a mobile >> device. That's not the matter here, but actually my TCL >> knowledge is limited (even more then my time, though it >> tends to switch over, slowly ;) and talking to the DGT is >> on a pretty low level resulting in a considerable amount >> of time for the development of dgtnix and especially its >> debugging. >> > > Windows CE is not the only issue : how DGT support will be > handled "out of the box" on Windows ? Fetch dgtnix and compile it, fetch dgtdrv2 and compile it, set up the proper path. In any case: the idea of the input engine approach is, that this is actually not even the issue of scid, how it is realised. It can and should be done by a third party project. I think this is a good approach as otherwise Scid will become a monster in due time. Yes, actually, I admit that I do not really like the "all in one box"-approach you favour. Ie. that currently Scid comes with a bunch of engines and databases and stuff that is all compiled all the time again. Its a huge package. I'd prefer it to be more modular there offering an independent download for the engines (there's a strong reason for Phalanx as I get it as you extened that one pretty much), for the books, for the databases and so on. But: if you want to include all that in one tar, I'll just silently drop out what I don't need when I run my Scid install and only use what I need from the package. E.g. all engines I use are either not from Scid or at least live in another dir as I use a Unix like setup and not the Windows-like one the current distribution favours. (Ie. scid is owned root:root and lives in /opt/chess/stow/... Stuff like that.) > Having written Novag citrine support in Tcl, I have no > need to even test it on Windows : it simply works because > it is written in a portable manner. Same with dgtnix and especially dgtdrv2. dgtdrv2 is actually pure POSIX C (I consider this a very protable language, though it has the drawback to require a compiler), I see no obvious issue there that it should not work. I just did never compile it on windows. (I really have none ;) dgtnix is know to run on windows according to Pierre who tested this and did quite some work in that area to be perfectly POSSIX compliant. I once took a Mac and both packages compiled out of the box without any warning or error. There is a konwn issue for dgtnix on the Mac (OS X) thoguh, but that's actually not a C issue, but has to do with handshake on serial lines and how it is handled on the Mac. Seems the Mac does not like serial com without either hard- nor softwarehandshake which is the default for the DGT. We'd need a skilled Mac-programmer to resolve this. Unfortunately, none of us owns a Mac and the necessary knowledge about the details to fix it. > And a nice side effect is that having written the code in > Tcl, to port it to windows CE is really straightforward > (minor adaptations). I agree with you, thats not the matter, but I still say: setting up dgtnix did really require some time and some work and there was already a sample implementation (namly dgtdrv ;) there done in C before. dgtnix itself is a bit larger than your whole Citrine code and this lib does not really give you even the concept of "move" but just a very basic messenging interface where again dgtdrv2 does all the "we make a move of it" stuff. It is again about the size of your Citrine code, and this is not cause it is in C ;) Its in fact a bit a complex thing to talk to a DGT board. So I just can't do it in TCL in just another day. (We invested about a year in dgtnix...) Currenlty the DGT not even talks to me on the serial line at all with my tries in TCL. I tried to implement the very basic ie. "give me your copyright message and serial number". This is actually "trivial" as you've just to send one byte and get back a real string. Besides that the whole DGT "api" is pretty C-ish anyway, all the time using bitfields and stuff to encode its messages and so on terminating with \0 or not depending on what I get back. Just look at the header file provided by DGT for the boards programming and there're a lot of nifty details that need to be taken care of. E.g. is the clock to whites right or left? (This actually defines the position of a1... You'll wonder what your engines does if you use the board upside down. Though actually you'll not have a problem then to get them out of the book. ;) If I've enough time I'll check into this again and maybe can come up with something done in TCL, but it is a bit work required here. Still I find the creation of an interface for "whatever may come" not the worst idea. ;) -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
