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.

[idefix2]

Ich vermute, es geht dir darum, dass die Abläufe immer gleich schnell wirken. Dabei ist es relativ egal, ob der einzelne Durchlauf 8, 10 oder 11 ms nach dem vorigen Durchlauf erfolgt, aber Fehler dürfen nicht akkumulieren.

Zu Beginn:

Code:

TickCountAtStart:=gettickcount;
StepCount:=0;

und
nach jedem Durchlauf:

Code:

inc(StepCount,TicksPerStep);
sleep(TickCountAtStart+StepCount-gettickcount);

[Mavarik]

So mach ich es auch...

Delphi-Quellcode:

procedure TMainTimeing.Execute;
var
 Timer : TStopWatch;
 MS    : Int64;
 FPS   : Single;
begin
  Timer := TStopWatch.Create;
  Timer.Reset;

  while not(GameEnd) do
    begin
      try
        Timer.Start;

        GameScreen.Bereinigen;
        GameScreen.BeginUpdate;
        try
          try
            FPS := PacMan.NextFrame;
          except
            MS := 1;
          end;
        finally
          GameScreen.EndUpdate;
        end;

        TThread.Synchronize(NIL,Procedure()
        begin
          PacForm.BeginUpdate;
          try
            PacForm.Image1.Bitmap.Assign(GameScreen.Screen[GameScreen.AktScreen]);
          finally
            PacForm.EndUpdate;
          end;
        end);

        Timer.Stop;
        MS := Timer.ElapsedMilliseconds;
        Timer.Reset;

        if MS < FrameRate then
          Sleep(FrameRate-MS);
      except
        GameEnd := true;
      end;
    end;
end;

[Medium]

Die Sache mit dem Sleep fällt jedoch komplett in sich zusammen, wenn der Code im Thread länger braucht als die maximale Sleep-Zeit nachher sein soll. Den negativen Wert kann man ja noch auf 0 clampen, aber wenn die gesamte Mechanik darauf ausgelegt ist, dass der Thread immer schneller als sein Intervall ist, bricht praktisch alles zusammen.

Ich gehe noch davon aus, dass es hier um die Frame-Update Methode geht, was der TE glaube ich noch nicht bestätigt hat:
Der einzig richtige Weg ist es, die Framerate überhaupt nicht zu kontrollieren, das kann eigentlich nur schief gehen. Entweder man lässt es so schnell laufen wie es geht, oder, wenn man DirectX oder OpenGL einsetzt, man limitiert auf V-Sync.
Der Kniff ist: Nicht die Framerate orientiert sich an der Spiellogik, sondern die Logik ist zeitlich skalierbar und an die Framerate anpassbar! Im Grunde muss man "nur" vorsehen, dass alle "Fortschritte", also alle zeitlichen Abläufe, ein gemeinsames Basisintervall annehmen, und dann einen Faktor entgegennehmen an den angepasst wird. Der Faktor ergibt sich dann aus der Verarbeitungsgeschwindigkeit von direkt davor.
Damit bleiben alle Abläufe konstant, ganz egal wie schnell der PC ist. Man hat zwar potenziell ein Frame "Lag", da man immer auf den letzten anpasst (an den aktuellen geht ja nicht), aber im Mittel kommt das sehr gut hin, krasse Sprünge sind eher selten, und in der Gesamtheit passt es - ganz ohne kumulierte Fehler. Alles andere ist Gehampel, dass einem früher oder später um die Ohren fliegt.

[hathor]

Zitat: "Ich möchte aber dass der Thread immer 10 ms braucht."

Da kann man alles, was mit SLEEP() oder SLEEPEX() zu tun hat, vergessen.
Es wird nur eine Mindestzeit "geschlafen", aber nach oben gibt es keine Funktionsgarantie, d.h. es kann auch mal 15,6 ms dauern, statt die gewünschten 1 bis 10.

SleepEx function

[Mavarik]

Zitat:

Zitat von hathor (Beitrag 1312938)

Zitat: "Ich möchte aber dass der Thread immer 10 ms braucht."

Eben... Er hat nicht geschrieben: alle 10ms auch wenn meine Berechnung länger dauert...

Also gehe ich mal davon aus, das er schneller brechnet...

BTW..: ohne den Sleep schafft meine Pucman routine 480-550 Frames.

[Dejan Vu]

@idefix2, @Mavarik: Siehe #5 :-D

[p80286]

Um noch einmal klar zu stellen was geschrieben wurde:

Zitat:

Zitat von Cubysoft (Beitrag 1312788)

Dabei soll eine Berechnung genau alle 10ms ausgeführt werden und das in einem anderen Thread.
...
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..

Gruß
K-H

[Mavarik]

Zitat:

Zitat von Dejan Vu (Beitrag 1312958)

@idefix2, @Mavarik: Siehe #5 :-D

daher

Zitat:

Zitat von Mavarik (Beitrag 1312857)

So mach ich es auch...

Zitat:

Zitat von p80286 (Beitrag 1312985)

Um noch einmal klar zu stellen was geschrieben wurde:

Logisch - Weil er in seinem Beispiel nicht die länge der Ausführung berücksichtigt hat und daher immer 10ms länger wartet...

[idefix2]

Eine andere Variante wäre es, via Timer alle 10 ms die Aktion zu starten - wenn du dich darauf verlassen kannst, dass du in 10ms immer fertig wirst.
Wenn die Timer Routine noch läuft, wird allerdings der nächste Durchlauf übersprungen, während bei der Variante mit sleep der nächste Durchlauf sofort angehängt wird, und wenn ein Durchlauf im Schnitt nicht länger als 10ms dauert, die Verspätung aufgeholt werden kann.

[Medium]

Hier in der DP steht bestimmt schon mehrere hundert Male warum ein Timer für präzise Timings, vor allem unter 40ms/25ms komplett ungeeignet ist. Du bist doch schon lange dabei idefix, noch nie grüber gestolpert? (Davon ab wären auch "perfekte" Timer ungeeignet, zumindest wenn es wirklich um die Framerate in einem Spiel geht. Leider hat der TE das Thema hier offenbar schon verlassen, Nachfragen werden ja nicht beantwortet. Von daher...)

[mm1256]

Zitat:

Zitat von Medium

Leider hat der TE das Thema hier offenbar schon verlassen

Ja, es sieht so aus.

Zitat:

Zitat von Medium

Hier in der DP steht bestimmt schon mehrere hundert Male warum ein Timer für präzise Timings, vor allem unter 40ms/25ms komplett ungeeignet ist

Mich würde mal interessieren, warum ein Timer - wie von mir bereits vorgeschlagen (der Timer in MMSystem, nicht die normale Timer-Komponente) - keine praktikable Lösung ist? Ich habe soeben mal einen Test mit 10.000 Durchläufen gemacht (also 10.000 * 10 ms => 100.000 ms) und die Abweichung gemessen. Bei 100 Sekunden gerade mal 6,8 Millisekunden. Also bitte, was veranlasst dich zu dieser Aussage?

[Mavarik]

Zitat:

Zitat von mm1256 (Beitrag 1313063)

Also bitte, was veranlasst dich zu dieser Aussage?

Was hast Du den während der Messung gemacht? Nix? Oder mal Datei oder Screen I/O?
Oder mal ne For-Schleife die 1 Minute läuft?

Hast Du mal ein anderes Programm gestartet (Word Delphi oder so...)

[Valle]

Windows ist nun mal kein Echtzeitbetriebssystem.

Entweder ich kann mich auf die Timings der Betriebssystem zu 100% verlassen; dann kann ich meine Algorithmen so auslegen, dass ich von einem exakt akkuraten Timing ausgehe. Bei Airbags oder diversen Industriemaschinen ist das notwendig. Der Airbag muss genau dann auslösen wann ich das will und nicht irgendwie 6,8ms früher oder später. Das ist Kompromisslos und auch der Grund warum Airbags zum Glück nicht von einem Windows gesteuert werden.

Oder die Timings meines Betriebssystems sind unzuverlässig. Sobald ich eine Abweichung habe, kann ich meine Logik nicht mehr auf ein exaktes Timing basieren lassen. In einem Spiel beispielsweise muss ich mir dann eine andere Methode suchen, um zeitdiskrete Berechnung auszuführen. Jede Millisekunde, seien es auch nur 6,8ms, sind zuviel und machen meine Logik kaputt. Wenn ich davon ausgehe 25 Frames in der Sekunde zu haben und stur in jedem 25. Frame 100 Punkte auf den Score addiere, dann ist das Spiel unfair und kaputt.

Auch wenn Multimedia-Timer bessere Qualitäten haben als der Standardtimer sind sie nun mal nicht perfekt. Und solange ich kein perfektes Timing habe, muss ich bei der Programmierung davon ausgehen, dass das Timing vollkommen kaputt ist. Nur so kann ich zuverlässige Algorithmen bauen.

(Btw, was die 6,8ms angeht. Lass mal ein Spiel oder ein Benchmark oder etwas anderes sehr rechenlastiges währenddessen laufen.)

[mm1256]

Zitat:

Zitat von Mavarik (Beitrag 1313072)

Was hast Du den während der Messung gemacht? Nix? Oder mal Datei oder Screen I/O?
Oder mal ne For-Schleife die 1 Minute läuft? Hast Du mal ein anderes Programm gestartet (Word Delphi oder so...)

Der Windows-Media-Timer wird in dieser Form vielen Multimedia-Anwendungen verwendet, z.B. beim Abspielen von Midifiles. Das sind sehr zeitkritische Anforderungen (ein Midifile darf ja nicht "leiern", Aussetzer haben oder dergleichen) wo parallel dazu noch andere Aufgaben (auch VCL) erledigt werden müssen. Mein Testprogramm war ganz einfach als VCL-Anwendung gestrickt. In der Praxis (und auch so wie vom TE gewünscht) lauft der Timer in einem eigenen Thread mit erhöhter Priorität. Ich hab mir die Arbeit für ein diesbezügliches Testprogramm jetzt nicht gemacht, aber die Abweichung liegt mit Sicherheit noch darunter, auch wenn parallel dazu andere Arbeiten erledigt werden.

Auszug, ohne Anspruch auf Vollständigkeit, eben nur mal schnell zum Testen:

Delphi-Quellcode:

implementation

uses MMSystem;

const
  MW_TIMER_TEST = WM_USER + 100;

procedure TimerCallBackProc(uTimerID, uMsg: Integer; dwUser, dwParam1, dwParam2: LongWord); stdcall;
begin
  PostThreadMessage(HWND(dwUser), MW_TIMER_TEST, 0, 0);
end;

procedure TFrmTimerTest.Start;
const
  MaxCount = 10000;
var
  TimerMsg: TMsg;
  TimerProc: TTimerProc;
  TimerInterval, TimerID, TimerCount, Counter: Integer;
  CloseRequested: boolean;
  TimerReturnMsg: Longbool;
begin
  Counter := 0;
  TimerInterval := 10;
  TimerCount := 0;
  TimerProc := TimerCallBackProc;
  TimerID := timeSetEvent(TimerInterval, TimerInterval, @TimerProc,
                          GetCurrentThreadId, TIME_PERIODIC);
  if TimerID = 0 then begin
    timeEndPeriod(TimerInterval);
    Exit;
  end;
  Memo.Lines.Clear;
  edStartTickCount.Tag := GetTickCount;
  edStartTickCount.Text := IntToStr(edStartTickCount.Tag);
  repeat
    TimerReturnMsg := GetMessage(TimerMsg, 0, 0, 0);
    Inc(Counter);
    if Counter > MaxCount then break;
    if TimerMsg.Message = MW_TIMER_TEST then
    begin
      Inc(TimerCount);
      // Anzeige, damit der VCL-Thread auch ein bisserl was zu tun hat
      Memo.Lines.Add('Count:'+IntToSTr(TimerCount));
    end;
    TranslateMessage(TimerMsg);
    DispatchMessage(TimerMsg);
  until (integer(TimerReturnMsg) <= 0);
  edStopTickCount.Tag := GetTickCount;
  edStopTickCount.Text := IntToStr(edStopTickCount.Tag);
  edDiffTickCount.Tag := edStopTickCount.Tag - edStartTickCount.Tag;
  edDiffTickCount.Text := IntToStr(edDiffTickCount.Tag);
  timeKillEvent(TimerID);
  timeEndPeriod(TimerInterval);
end;

[Valle]

Zitat:

Zitat von mm1256 (Beitrag 1313083)

Der Windows-Media-Timer wird in dieser Form vielen Multimedia-Anwendungen verwendet, z.B. beim Abspielen von Midifiles. Das sind sehr zeitkritische Anforderungen (ein Midifile darf ja nicht "leiern", Aussetzer haben oder dergleichen) [...]

Ah, sehr gutes Beispiel. Da Video und Audio natürlich nicht stottern dürfen, muss trotz fehlender Garantie von Rechenzeit sichergestellt sein, dass immer genug Daten zum Abspielen vorgehalten werden. Deshalb besitzt der Computer eine Soundkarte mit einem Audiobuffer. Dieser muss gelegentlich aufgefüllt werden. Wie die Abstände zum Auffüllen genau sind, spielt keine Rolle. Wichtig ist nur, dass das passiert, bevor der Puffer leer ist.

Bei alten PCs passierte es noch öfter, dass die Musik aussetzt, wenn man die CPU zu sehr beanspruchte. Heute passiert das kaum mehr, allerdings bemerkt man diesen Puffer noch, falls es mal zu einem Bluescreen kommen sollte. Noch heute wiederholt mein PC die letzte Sekunde des aktuellen Songs dann in einer Endlosschleife.

Die Lösung des Problem ist also der Puffer in der Soundkarte. Nicht (nur) der Multimedia-Timer.

[Perlsau]

Um ein laufendes Video zum Stottern zu bringen, genügt es meiner Erfahrung nach bereits, neben dem Zugriff auf die Festplatte durch den Videoplayer ein oder zwei weitere Zugriffe auf dieselbe Festplatte anzuleiern, z.B. einen Kopier- und ein Entpackungsvorgang. Auch Midi-Files stottern beim Abspielen, wenn man gleichzeitig weitere Zugriffe auf dieselbe Platte hat. Das hat mit der Rechenpower im Grunde nichts zu tun, sondern ist dem "Flaschenhals" Festplatte geschuldet. Beim Video kommt es natürlich, wie oben bereits erwähnt, auf den Videopuffer an, aber auch auf die Video-Auflösung, denn je höher die Auflösung, desto mehr Daten fallen pro Sekunde an.

[mm1256]

Zitat:

Zitat von Perlsau (Beitrag 1313086)

....Auch Midi-Files stottern beim Abspielen, wenn man gleichzeitig weitere Zugriffe auf dieselbe Platte hat. Das hat mit der Rechenpower im Grunde nichts zu tun, sondern ist dem "Flaschenhals" Festplatte geschuldet....

Weil OT, nur kurz zur Info: Ein normales Midifile wie es von Musikern verwendet wird, ist i.d.R. nicht größer als 150 kb. Beim Laden des Midifiles werden die darin enthaltenen Midi-Events in eine Liste (bei Delphi-Playern überwiegend von TList abgeleitet) in den Speicher geladen. Während des Abspielens erfolgt keinerlei Zugriff auf den Datenträger. Darum kann dieser z.B. auch eine SD-Karte sein. Die Schlussfolgerung "Flaschenhals" Festplatte ist in diesem Fall nicht zutreffend.

[Dejan Vu]

Da sonst mit Puffern gearbeitet wird, spielt das eh keine Rolle.

Es geht ja auch darum, dass das mit der Echtzeitfähigkeit nicht so richtig funktioniert, wenn während des Abspielens ein anderer Prozess am werkeln ist. Nochmal: Windows ist nicht realtimefähig und daher kann man sich nun einmal nicht darauf verlassen, das irgend ein Timer immer perfekt auslöst.