Absender: Ansgar Esztermann
Datum: Mi, 05.04.2006 12:52:11
In-reply-to:
<812F86EC9E1A96489D5E83C2AB7D68860FCB07@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<812F86EC9E1A96489D5E83C2AB7D68860FCB07@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Hallo, > Aber für komplexere Dinge müssen erst einmal die grundsätzlichen Dinge in den Griff bekommen werden. So klappt es bei mir (bei Euch sicher auch nicht) z.B. nicht, ein funktionierendes bot_goto Verhalten zu haben mit gleichzeitig richtig zählender Maus. Beides einzeln wunderbar. Bot_goto muß aber das delay(10), was wohl 100 ms Wartezeit bedeutet, haben. Die Maus darf das delay nicht haben. Und hier genau bin ich am Verzweifeln, siehe dazu: Ich hatte schonmal vorgeschlagen, dafür die delay()-Implementierung zu ändern. Ich bin aber auch nicht dazu gekommen, mir da weitere Gedanken zu machen. Die Idee ist die, daß man Prozessorzeit nicht sinnlos verbrät, sondern stattdessen aus dem Verhalten herausspringt und zunächst die anderen Verhalten abarbeitet, indem man für jedes Verhalten zusätzlich eine Variable delay_until mitführt. Das Verhalten wird dann erst wieder angesprungen, wenn diese Zeit erreicht (oder überschritten) ist. Wenn man nicht direkt eine komplette Thread-Verwaltung aufbauen will (m.E. übertrieben), müßte sich jedes Verhalten dann noch selbst darum kümmern, bei erneutem Aufruf das richtige zu machen (also ggf. weiter unten die Arbeit fortzusetzen): void tu_was() { if (delay_until) { delay_until = 0; /* Aufruf bei jeder Runde durch die Verhalten */ goto weiter; } ... /* Arbeit */ if (bedingung) { delay_until = now()+10; /* Annahme: es gibt eine Systemzeit in ms */ return; } weiter: ... /* Arbeit */ } A. -- Ansgar Esztermann Researcher & Sysadmin http://www2.thphy.uni-duesseldorf.de/~ansgar
Attachment:
pgpDW0yfEUf3c.pgp
Description: PGP signature