Zitat von
Solwac
Ich gehe mal in einen neuen Strang, weil es ja nicht auf einen Computer beschränkt ist.
Sehr gut, danke.
Zitieren:
Ich kann seit HGMs Übernahme der Entwicklung nicht sehen, dass XBoard tot sei.
Ja, es wird gnadenlos aufgebläht. Besonders, weil Winboard nicht mehr auf Schach ausgelegt ist, sondern auf Schach-Varianten, die sowieso niemand spielt. Jüngstes Beispiel ist das Disaster um die Entsprechung zu "searchmoves". Das will man einfach nicht mehr supporten.
Zitieren:
XBoard ist relativ leicht zu programmieren, man muss es halt einmal machen und das war es.
Das ist mit UCI noch viel mehr der Fall. Aber mit Winboard hast Du haufenweise Absurditäten. Beispiele? Naja, es gibt "setboard", mit FEN-String. Schön, nur leider kann die GUI das auch abweisen. Damit bist Du bei dem edit-Drama.
Oder searchmoves. UCI? Machste searchmoves. Winboard? Da hast Du dann searchmoves und das Gegenteil, excludemoves. Nur deswegen, weil die GUI bei Schachvarianten nicht weiß, welche Züge denn legal wären. Ein weiterer Befehl "getlegalmoves", der das gelöst hätte, wäre zu einfach gewesen. Damit hätte die GUI bei reinen Schach-Engines selber wissen können, was legal ist, und bei Varianten nachfragen können.
Undo/Redo? Mit UCI bekommst Du einfach das position-Kommando. Winboard? Da kriegste "remove". Obwohl, nee, mit Arena stattdessen zweimal "undo". Ist die Engine eigentlich selber am Zug, wenn es nur einmal "undo" gibt? Nicht spezifiziert. Und wenn's zweimal "undo" gibt, ist die Engine dann am Zug oder hat man eine race-condition, weil sie nach dem ersten Undo am Zug war, dann gezogen hat, das zweite Undo bekommen hat und nochmal gezogen hat? Man weiß es nicht.
Ich hatte, real-Life, für die WB-Version unter "Chess for Android" die Bugmeldung, daß rausgehen aus der Anwendung und wieder reingehen nicht geht. Ich habe aber kein Smartphone und kann das somit nicht testen. Was auch immer die GUI dann wohl tun mag, wenn man das macht, ich weiß es nicht. UCI? Kein Problem, ist sowieso zustandslos.
Schlimmstenfalls bekommt meine Engine nicht mit, daß der eingegebene Zug zur selben Partie gehört und löscht daher irrtümlich ihre Hashtabellen und verwirft die Hauptvariante, aber das ist lediglich ein Performance-Problem.
Zitieren:
Lernen nach der Partie ist zwar ein Grund gegen UCI, aber meine Engines haben das nie benutzt.
Ich sehe da eh nicht, wo das Problem liegen soll. Die Engine weiß ja, daß sie am Gewinnen ist, also kann sie auch lernen. Wenn man in der Partie auf besser als +3.00 steht, dann ist das auf Gewinn. Es ght doch vor allem um Eröffnungsvarianten, und wenn die Engine zwar auf 3.00+ steht, aber ihrem eigenen Urteil nicht vertraut, dann wäre das wohl eher die Baustelle.
Zitieren:
Die propagierte Einfachheit von UCI kann ich nachvollziehen, da Eröffnungen oder Enspiele auf die GUI zurückgreifen können.
Nein, das ist es nicht. Meine Engine hat sowohl Eröffnungen als ganz wesentlichen Teil ihres Stils (geht ja auch mit UCI) als auch implementierte Endspiele. Daß die komplette Zugliste übergeben werden muß - eine sehr stumpfsinnige Arbeit. Computer sind in genau solchen Sachen aber sehr gut, weswegen jede GUI das einfach automatisert, womit es zum non-issue wird.
Gut, man kann das auf Commandline dann nicht mehr einfach nutzen, wenn man ein schlechtes Terminal hat, was mit Pfeil-oben nicht die vorige Zeile wiederholt. Deswegen haben die beiden Nutzer, die Desktoplinux mit Schach-Engines ohne GUI nutzen, aber einfach entsprechende EMACS-Makros.
Zitieren:
Damit entscheidet die GUI massiv über die Akzeptanz, so wie Du es ja mit den Testern auch erlebst.
Auch ein Gesichtspunkt, ja. Bevor ich dem Wahnsinn erlag, einen Schachcomputer bauen zu wollen (also eigentlich wollte ich ja bloß mal Erfahrung mit aktuellen Cortex M4 sammeln..), habe ich die Shredder-GUI verwendet. Wie schlichtweg genial die ist, habe ich nie wirklich bemerkt.
Bis ich Arena verwendete. Alles im Vergleich irgendwie zäh. Und Winboard, was einfach nur der Horror ist. Wenn Linuxer CLIs so mögen, liegt es auch daran, daß man damit einem Horror wie Xboard entkommen kann. Die wissen gar nicht, was richtige GUIs leisten können.
Das gesamte Ökosystem für Winboard ist einfach Steinzeit. Starte mal Winboard selber. Da kriegste einen abstrusen Dialog, der überhaupt nicht existieren sollte. Danach ist man per default im 5-Minuten-Blitzmodus. Zeitdruck also. Das ist mit Sicherheit das Allerletzte, was ein neuer User will. Die Eingabe für Stellungen ist furchtbar. Das Einfügen neuer Engines über diese Liste ist gruselig. Und für Crafty darf man dann auch noch mit einer rc-Datei herumfrickeln. Außerdem sieht Winboard dermaßen häßlich aus, daß mir die totale Abwesenheit jedweden Sinnes für Ästhetik nahezu physisch wehtut.
Kurzum, aus Anwendersicht ist das dermaßen schlecht, daß ich für die Shredder-GUI alleine, ohne Engine, locker 20 Euro bezahlen würde. Nur um diesem Horror zu entkommen. Leider verwendet die Shredder-GUI diesen WB2UCI-Krams, und in der Praxis funktioniert das nicht besonders gut.
Zitieren:
UCI deutlich mehr Speicher benötigt.
Ich sehe nicht, wofür. Die Zugliste muß für Undo sowieso komplett verwaltet werden. Nur auf meinem Cortex-M4 stoße ich an Grenzen, weil das gebufferte Backup-RAM halt nur 4 kB groß ist. Damit gehen nur 40 Halbzüge Undo / Redo mit Zeitverwaltung. Das ist für Raspi und PCs aber doch ein Witz.