Thread GENAU alle 10ms ausführen

[Cubysoft]

Hallo,

Gleich vorab: ich kann Codebeispiele nur sehr schlecht posten, da ich im Ausland bin und hier nur mit dem Handy reinkomme.

Nun zu meiner Frage: ich programmiere derzeit ein kleines Spiel. Dabei soll eine Berechnung genau alle 10ms ausgeführt werden und das in einem anderen Thread. Bis jetzt habe ich einen Runner Thread der immer im Hintergrund läuft (was auch am besten so bleiben soll). Der ist so aufgebaut:

While true
CODEBLOCK
SLEEP (10)
*WHILE

Problem ist nun halt, dass die Berechnung hierbei stark von dem benutzten PC abhängt. Wenn der Codeblock bei schnelleren PCs 5ms braucht, braucht er bei langsamen vllt 10. Ich möchte aber dass der Thread immer 10 ms braucht. Und nicht wie bei dem Beispiel 15ms oder 20ms..

Habt ihr da eine Idee?

[mensch72]

mehrteilige Antwort:
1. egal wie "genau" Windows die 10ms einhält, wenn dein Code länger wie 10ms braucht, wird das nix... da dann nur schnellerer PC, weniger machen, besser programmieren
2. als Timer/RunnerThread wäre minimal sinnvoll "while(not Terminated) do begin Sleep(10); SetEvent(xxx); end;"
3. als WorkerThread(s) wäre minimal sinnvoll "while(not Terminated) do begin WaitForEvent(xxx,TimeOut); if not "TimeOut" then CallWorkProc; end;"

Timer/RunnerThread der ja "nur" SetEvent macht kann "HighestPriority" laufen. WorkerThread kann "HigherPriority" laufen. Wenn ein ThreadPool an Workerthreads und eine MehrkernCPU, dann dürfte eine Ausführung sogar mal notfalls etwas länger wie 10ms dauern, weil ja ein anderer Kern den nächsten TimerEvent übernimmt und noch teils "halbparallel" ausführt.

Das sind aber alles keine Aufgaben, welche eine Usermode Delphi Anwendung so hart zeitkritisch bearbeiten sollte, dann lieber ein eigener Treiber per DDK im Kernelmode und es wird realistisch beherrschbar.
Ich definiere das Timing von Threads lieber so: es dauert alle "mindestens" solange wie da angegeben(also hier immer mindestens 10ms), es kann aber auch "länger" dauern.

Per HighPrecisionTimerMode kommt man so wie oben kurz beschrieben mit aktueller Hardware und Win7..10 durchaus auf +/-5ms Genauigkeit... also man könnte 10..15ms zu 98% erreichen. Aller neueste Systeme gehen auch 5msec +/-2 wenn man ohne IO Treiber Nutzung nur im Ram arbeitet... aber da ist Windows im UserMode dann wirklich am Ende dessen, was mit sinnvollem Aufwand an zu 98% "quasi garantierten" Zeiten möglich ist.

[Uwe Raabe]

Zitat:

Zitat von mensch72 (Beitrag 1312797)

dann lieber ein eigener Treiber per DDK im Kernelmode und es wird realistisch beherrschbar.

Echt jetzt - für ein Spiel? Ich würde eher sagen, daß die Architektur des Spiels nochmal überdacht werden sollte, damit sie nicht so zeitkritisch ist.

[p80286]

Zitat:

Zitat von Cubysoft (Beitrag 1312788)

While true
CODEBLOCK
SLEEP (10)
*WHILE

Da braucht jeder Schleifendurchlauf mindestens 10ms!
Was genau willst Du eigentlich erreichen? Ich tippe auf Bildaufbau mit 100 Hz?

Gruß
K-H

[Dejan Vu]

neben der Problematik, das du es so eh nicht hinbekommt, GENAU alle 10ms etwas auszuführen (wg. 'Sleep'), kann man bei längeren Intervallen durchaus so vorgehen:

Delphi-Quellcode:

while true do begin
  start := GetTickCount; 
  DoSomething();
  Elapsed := GetTickCount - start;
  if Elapsed < TotalWaitingTime then Sleep (TotalWaitingTime - Elapsed);
end;

Du wartest also 'TotalWaitingTime' abzüglich der für den Berechnungsvorgang benötigten Zeit. Du kannst aber nicht davon ausgehen, das 'DoSomething' immer in exakt gleichen Intervallen aufgerufen wird. Kann ja sein, dass das OS kurz einen Schluckauf hat.

Daher musst Du deine Berechnungen (Zeitabhängige Bewegungen, schätze ich mal) so ausführen, das Du nicht das 'konstante' Intervall berücksichtigst, sondern die Differenz zwischen letzter Berechnung und jetzt. Dann laggt das Spiel zwar vielleicht immer noch, aber wenigstens sind die Bewegungen gleichförmig.

[mkinzler]

Dabei muss man aber beachten, dass Windows nur bedingt echtzeitfähig ist.

[Rollo62]

Zitat:

dann lieber ein eigener Treiber per DDK im Kernelmode und es wird realistisch beherrschbar.

Da würde ich schon eher so ein fertiges Realtime-System einsetzen, das sollte es auch hinbekommen.
http://www.kithara.de/de/produkte/realtime-suite
Ob sich das einfach installieren lässt weiss ich nicht, es scheint sich tief in den Unterbau von HAL einzuklinken, und dein Windows ist womöglich nicht mehr das was es mal war.

Aber wie schon zuvor gesagt: Für ein Spiel ???

Könnte aber sein das manche Spiele soetwas nutzen ?


Rollo

[mm1256]

Und warum sollte man keinen Timer nehmen?

Code:

function timeSetEvent; external mmsyst name 'timeSetEvent';

[Uwe Raabe]

Zitat:

Zitat von Rollo62 (Beitrag 1312817)

Da würde ich schon eher so ein fertiges Realtime-System einsetzen, das sollte es auch hinbekommen.
http://www.kithara.de/de/produkte/realtime-suite

Für zeitkritische Steuerungsaufgaben (PLC, CNC) ist das schon ein wirklich gutes Produkt. Allerdings nehmen die Herrschaften auch Lizenzgebühren pro Installation, die locker mit dem Preis für die meisten "großen" PC-Spiele mithalten können. Ich wage deshalb mal die Behauptung, daß kein PC-Spiel diese Engine einsetzt.

[BUG]

Idealerweise verzichtet man heutzutage auf feste Framerates. Man misst man die Zeit des letzten Schrittes und berechnet quasi, was in der Zeit passiert ist.
Wenn ein festes Zeitraster aus technischen Gründen für dein Spiel wirklich nötig ist, dann kannst du das von der Ausgabe entkoppeln (die vermutlich die meiste Zeit frisst). Nur wenn noch Zeit ist oder eine bestimmte Zielframerate unterschritten wird, kann ein neues Bild gerendert werden.