Smirf timing

[H.G.Muller]

I continue to have problems running Smirf under Smirfoglot, even at time controls that are not really that fast, like 15 min sudden death (ponder on). It keeps forfeiting a large fraction of the games on time (11 out of 35).

I already reduce the time Smirfoglot passes to the SmirfEngine by 1%, to account for communication delays, but it doesn't help. There really iseems to be something fundamentally wrong in the way Smirf distributes its time over the game. I am not sure if pondering contributes to it. At 60-min sudden-death with ponder off there was not a single time loss. The distribution of time over the game is very uneven, though: it uses about 60% for the first 20 moves. This causes it to lose frequently in the final phase, when the opponent can affort to search 5 times longer. Smirf does speed up in this phase, but at some point it simply has not enough time left to do the moves. (And even if it would, the moves would be of such low quality, that it would be pointless to play on.)

With N moves per M minutes time losses do not occur, as in this non-native-Smirf mode, Smirfoglot controls the time that Smirf can use next move by move. W.r.t. time losses this works much better than letting Smirf distribute its own time, but it denies Smirf the possibility to think long when it would recognize that this is really needed.

I really think that you have to adjust some parameters here.

[Tony Hecker]

Hopefully Reinhard could help with this problem (regardless whether it's a Smirfoglot problem or Smirf problem).

Does the Smirf engine behave the same way under the Smirf GUI, resulting in time losses? If not, I wonder what the GUI is doing differently.

[Reinhard Scharnagl]

You see from all this, that SMIRF had no experience in automated games. It has been developed until its current state merely by investigating its behaviour by my own eyes. The time distribution has mainly intended to work for sudden death timings with additional Fischer time. Thus when the remaining time is becoming low, SMIRF's move qualitiy is sinking obviously, because it is intended as a positionally working engine. Playing Blitz though is not its working field.

A lot of details in SMIRF might be improved. But until now I cannot do automated games myself.

[H.G.Muller]

This is why I am giving you the feedback. I am sure I could solve the timeing problem by letting Smirfoglot fool the SmirfEngine into thinking that it has, say, only 60% of the time that it really has. But I don't want to do that, as it is not the task of an adapter. Smirf should behave under Smirfoglot as closely as possible to what it would do in its own GUI. So compensating for a little communication delay is OK, but it should not radically mess up Smirfs native time management. I did add a classical time-control mode by translating N moves per M minutes into 1 move per (M/N) minutes, which I considered close enough to be acceptable (although it is really a bit more restricted, forcing the engine to respect intermediate time-control points after every move).

I am sure you wil solve the problems with automatic play really soon. Did you already put winboard.exe and Joker80.exe or TJchess10x8.exe in your Smirf directory?

[Reinhard Scharnagl]

For owners of a personal key set only there is a new donators' bonus version of SMIRF's engine MS-171b at http://www.10x8.net/down/SmirfEngine.dll.

I hope the timing problems will have decreased with that.

[Reinhard Scharnagl]

There also is a renewed SMIRF FullChess GUI including its updated donationware engine BC-171c at http://www.10x8.net/down/SmNewSetup.exe.

[F.Huber]

There also is a renewed SMIRF FullChess GUI including its updated donationware engine BC-171c at http://www.10x8.net/down/SmNewSetup.exe.

Hallo Reinhard,

ich würde mir wünschen, daß auch die neueren SmirfGUI-Versionen wieder auf einem 800x600-Bildschirm funktionieren. Die letzte Version, die das noch konnte, war vom 22.9.2007, und daher benutze ich auch nur diese. Alle neueren sind auf meinem Notebook nicht mehr benutzbar, weil alle Teilfenster (z.B. Brett, Zugliste) zu groß sind und sich überlappen und dadurch das untere Viertel (Zeiteinstellungen, Analyse, ...) überhaupt nicht mehr sichtbar sind.
Vielleicht könntest Du das ja mal korrigieren?

Grüße,
Franz.

[Reinhard Scharnagl]

Auch, wenn man zuvor die "size=" Angabe in der INI Datei gelöscht hat?

[F.Huber]

Auch, wenn man zuvor die "size=" Angabe in der INI Datei gelöscht hat?

Hab´s eben mal probiert (sowohl gelöscht als auch einen kleineren Wert als den Standard 600 eingegeben): nützt auch nichts, es wird das gesamte Programm-Fenster kleiner, das Brett bleibt immer noch riesig und verdeckt fast alles andere.

[Reinhard Scharnagl]

Ok, dann wird es in Kürze eine Korrektur geben.

[F.Huber]

Ok, dann wird es in Kürze eine Korrektur geben.

Das wäre wirklich nett!

Übrigens müßtest Du Dir das auch selber einfach ansehen können, wie es bei 800x600 aussieht, denn eine höhere Bildschirmauflösung läßt sich normalerweise recht einfach auf eine niedrigere zurücksetzen:

- Rechtsklick auf den Desktop
- Klick auf Eigenschaften
- Klick auf den Reiter Einstellungen
- und schließlich mit dem Schieberegler die Auflösung vermindern

Geht zumindest unter Windows98 so, bei XP müßte es ähnlich funktionieren.

PS. Übrigens is mir noch aufgefallen, daß die neueren SmirfGUIs die Einstellung "Gegnerzeit nutzen" nicht mehr in der INI abspeichern (als "Ponder=1"). Ist das ein Versehen oder Absicht?

[Reinhard Scharnagl]

So, da gab es ein Problem mit Autoscaling bei gröberen Bildschirmauflösungen. Ich hoffe nun, es behoben zu haben. Hierzu wäre ein Feedback dann nicht schlecht.
Der Pondermodus wird absichtlich nicht mehr zwischengespeichert. In bestimmten Situationen (langsame Prozessoren, virtuelle Betriebssysteme) konnte es zu unbeabsichtigten Blockaden des Rechners beim Programmstart führen. Also sollte es jeweils mit Absicht neu gesetzt werden.

[F.Huber]

Ja, jetzt klappt es wieder, vielen Dank!

Eine Kleinigkeit noch: obwohl es ja keine besonders wichtige Funktion ist, aber die Zuggeräusche funktionieren auch nicht mehr, und zwar schon seit längerem. Meine letzte (noch ´musikalische´) Smirf-Version ist vom 28.5.2007.

[Reinhard Scharnagl]

Soweit - so gut. Das mit dem Sound ist mir selber bereits aufgefallen, jedoch habe ich dafür keine richtige Lösung. Es betrifft offenbar nur ältere Windows Betriebssysteme, auf XP und Vista dagegen kommt der Sound.

Meine Vermutung ist, dass dies mit den Borland/Codegear Laufzeit-DLLs zusammenhängt. Denn es geschieht erst seit der Umstellung auf die freie Codegear C++ Turbo Version. Doch mit den veralteten DLLs der Vorversion wollte ich nicht noch Austausch-/Verträglichkeitstests machen - das wäre bestimmt eher die Aufgabe von Codegear.

Die Sounddateien sind ja nicht geändert worden, und der Aufruf ist ebenfalls identisch geblieben.

Da Borland/Codegear vorerst nicht beabsichtigt, unter C++ 64 Bit zu unterstützen, Microsoft in neueren Visual Studios die C++ Programmierer stets systematisch vergrault, ältere Tools komplett entwertet und zudem wieder Geld für jedes neues Studio haben will, beschloss ich den Umstieg auf Mac OS. Daher werde ich auch keine neuen Windows Entwicklungsumgebungen mehr erwerben - zumal jede Umstellung doch einiges an Kosten verursacht und die spendenden Unterstützer leider ausbleiben.

[F.Huber]

Meine Vermutung ist, dass dies mit den Borland/Codegear Laufzeit-DLLs zusammenhängt.

Kann ich mir eigentlich nicht vorstellen, denn auch mit den aktuellen DLLs der jetztigen Version (also von gestern) liefert die alte SmirfGUI.exe vom 28.5.2007 noch Zuggeräusche, aber die neue GUI nicht mehr.

Aber wie schon gesagt: ist nicht wirklich wichtig ...

[Reinhard Scharnagl]

Die Bibliothek "winmm.dll" ist zwar auf älteren Win-OS etwas anders, aber daran liegt es wohl nicht. Ich habe gelesen, dass manchmal die Hardwarebeschleunigung heruntergeregelt werden muss bei WAV Dateien von hoher Sampling-Rate. Dann ist mir aber wieder das Funktionieren der alten Version ein Rätsel.

Ich habe eine neues Donation-Version-Paket mit einer etwas geänderten Einbindung von schwächer gesampleten WAVs zum Download bereitgestellt. Vielleicht klappt es ja damit dann wieder auch auf Windows 2000, Windows 98 und Windows ME.

Da ich alle diese Systeme nicht mehr oder (W2K) nur als Simulation zur Verfügung habe, bin ich für Rückmeldungen stets dankbar.

[F.Huber]

Das war´s, jetzt ´spricht´ Smirf auch wieder!

Vielen Dank,
Franz

[Reinhard Scharnagl]

Does the new SMIRF engine still have those problems?

[Reinhard Scharnagl]

Despite of SMIRF MS-172c seems to be a stable engine finally, I decided to rework the recognition of quiet positions, thus starting a MS-173 serie. After some very unbalanced attempts there now MS-173e-X is available. I hope that the X approach at its end will culminate in a somehow stronger SMIRF version. But we will see ...

Reinhard.