Hallo,

ich schreibe grade eine Serveranwendung für einen Frogger Klon. Die Serveranwendung soll u.a. Autos mit möglichst konstanter Geschwindigkeit fortbewegen. Im (noch Singleplayer) Client wurde ein auf 5ms "getakteter" TTimer verwendet, welcher effektiv aber nur alle ~15ms "feuert". Die Serveranwendung soll nun eine präzisere Variante benutzen. Ich habe eine whileschleife in einem eigenen Thread welche die Prozedur in der die Autos bewegt werden auslöst. Das mit der Zeit habe ich versucht so zu Lösen.



Geplant sind also, mindestens 5ms vergehen zu lassen. Da das Bewegen der Autos und auch die anderen Berechnungen nicht sehr komplex sind sollte es eigentlich kein Problem sein die Schleife schneller als in 5ms zu durchlaufen. Wenn dem so war, wird die Restzeit abgewartet.

Die eigentliche Frage. Wie sieht die elegantere Möglichkeit aus, eine Schleife mit möglichst konstanter Frequenz/Rate zu Wiederholen?

MfG donald

Hey,

das ist nur schwer möglich. Bei Windows wirst du _nie_ unter 16ms kommen, weil das die kleinste Zeiteinheit ist, die ein Thread schlafen gehen kann. Um wirklich ein genaues sleep zu bekommen könntest du dir eine while(true) Schleife bauen, mit QueryPerformanceCounter die Zeit berechnen und wenn die Wartezeit vorbei ist die Schleife beenden, das ist aber in heutigen Programmen eher ein NO-GO!
Moderne Programme arbeiten alle mit TimeBased-Movement. Hier ein wenig pseudo-Code:

Mit de Methode hast du zwar immer noch kein genaues Intervall, dafür aber eine genaue Bewegnung, da die Bewengung der Objekte von der Zeit abhängig ist.

€: 5ms sind meiner Meinung nach auch völlig übertrieben, 50ms sollten völlig ausreichend sein. Ich schalte bei meinem OpenGL Programmen immer vSync an, dann blockiert SwapBuffers solange bis der Monitor bereit ist ein neues Bild auszugeben. Bei einem 60Hz Monitor wären das ca. 16ms.

MfG Bergmann.

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Das habe ich schon oft gelesen, was aber nichts daran ändert, dass es schlicht falsch ist. Um sicher zu gehen, habe ich es gerade nochmal ausgetestet. Ein Sleep(0) hat in einem Fall sogar nur 1 µs gebraucht.

Ist richtig, hat aber mit dem Problem nichts zu tun. Timebased Movement dient lediglich dazu, das Spielgeschehen auf verschieden schnellen Rechnern gleichschnell ablaufen zu lassen. Eine schwankende Framerate führt aber auch mit TBM unweigerlich zu Mikrorucklern (wobei das "Mikro" nicht "winzig" bedeutet, sondern nur die Art des Rucklers klassifiziert).

50 ms entsprechen 20 fps. Das ist zum Rendern zu wenig.

Vorsicht übrigens: sleep() (POSIX) und Sleep() (Windows) sind nicht dasselbe. Ersteres erwartet eine Zeitangabe in Sekunden und letzteres in Millisekunden.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Auch wenn schon geschlossen, meine Methode für Framelimit mit TBM:



(SDL_Delay entspricht Sleep ; SDL_GetTicks entspricht dem QueryPerformanceCounter)

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Hey,

sleep(0) ist eine Ausnahme und kehrt sofort zurück. Alles was drüber ist wartet mindestens die Zeit eines System Ticks und der ist bei Windows 16ms: Hier steht alles schwarz auf weiß.

Da geb ich dir recht, aber da es hier um den Server geht hat man auch dementsprechend kein Bild. Der kümmert sich nur um die Bewegung und da sollten auch 50ms ausreichend sein. Den Microrucklern kann man mit Double- oder Tripple-Buffering entgegen wirken. Ich hatte da mal n sehr gutes White-Paper dazu, das find ich aber leider nicht mehr

MfG Bergmann

_________________
Aktuelle Projekte: BumpMapGenerator, Massive Universe Online
Auf meiner Homepage gibt auch noch paar Projekte und Infos von mir.

Da steht nur, dass Sleep höchstens so genau wie ein System Tick ist. Dass dieser 16 ms lang ist, steht da nicht und das ist auch nicht wahr. Andere Zeiten, die ich vorhin (nicht mit 0) gemessen habe, waren irgendwas mit 2700 µs und 6100 µs. Und nochmal möchte ich auf den Unterschied der beiden Funktionen hinweisen, da du schon wieder ein kleines s geschrieben hast, dein Link aber auf Sleep verweist.

OK, das kann je nach Anwendung durchaus sein. Wenn allerdings der Server nur alle 50 ms die Autos weiterbewegt und die Clients das einfach übernehmen, bringt es auch nix, denn wenn der Client 100 fps hat aber 5 Frames hintereinander das selbe Bild zeigt, hat man effektiv wieder nur 20 fps.

Nein, der Zusammenhang war anders: Triple-Buffering beseitigt das Problem der Frameraten-Halbierung beim Einsatz von V-Sync. Das wird allerdings mit zusätzlichen Mikrorucklern erkauft. Steht übrigens auch im Wiki:
http://wiki.delphigl.com/index.php/Framerate#Bildschirmfrequenz_und_V-Sync

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

http://wiki.delphigl.com/index.php/Frameratenbegrenzung
Ich hatte eigentlich gehofft, dass der Artikel es erklärt aber scheinbar war ich nicht gut genug da drin.
Sleep(1); sagt das der Prozess-Thread 1ms schlafen soll und nicht wie lange er wirklich schlafen wird.
Wie lange der Thread wirklich schläft, hängt davon ab, wie lang die Time-Slice ist, wo im Slice der Thread gerade ist, wie genau der Timer ist, wie viele Kerne verfügbar sind und was die anderen Prozesse machen.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms682105%28v=vs.85%29.aspx
Sleep(0) hat SuspendThread Eigenschaften.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684831%28v=vs.85%29.aspx
Das zeigt die Problematik von Thread Prioritäten und wenn systemfunktionen nicht nicht fertig werden.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms685100%28v=vs.85%29.aspx
Die Priorität bestimmt die Time-Slices, Agner Fog hatte geschrieben, dass in seinen Studien raus kam, dass Normale Prozesse 16ms Slices haben und Echtzeit Prozesse 120ms.
Wenn man nun ein Normalen Prozess für 16ms schlafen legt und der PC nur 1 Kern hat, dann würde ein Echtzeit Prozess, der keine System Funktionen aufruft und seine volle Zeit nutzt dafür sorgen, dass der normale Prozess minestens 120ms schlafen würde.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms684247%28v=vs.85%29.aspx
Der Multimedia Timer läuft über ein anderen Sheduler, der es ermöglicht den normalen Sheduler zu umgehen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004