2009-04-09 12 views
2

Ich muss meine Spielschleife mit sehr genauem Timing ausführen. Ich versuche NSTimer zu benutzen, und ich bekomme gute Ergebnisse, aber es gibt ein bisschen Drift. Wenn NSTimer ausgelöst wird, beginnt das Ereignis das nächste Mal mit dem Zählen, wenn der Handler fertig ist, oder fängt es sofort an zu zählen. Wenn der erste ist es vernünftig für mich, setFireDate verwenden, um zu versuchen, den nächsten Timer-Feuern auszugleichen - als ich das versuchte, schien es schlimmer.Verwenden von NSTimer, um genaue Zeiten zu erhalten

Mein Timer ist so eingestellt, dass er alle 44ms abfeuert und ich möchte das Driften um mehr als 20ms stoppen. Wenn es driftet, möchte ich es für das nächste Feuer korrigieren. Ist das eine vernünftige Sache mit NSTimer zu versuchen?

+0

20ms auf 44ms ist keine Drift, das ist ungenau. NSTImer sollte viel zuverlässiger sein. –

+0

Ich denke, was ich sagen wollte, war, dass ich die Zeit brauche, die meine Schleife läuft, um nicht abzudriften. Von dem, was ich sagen kann, startet der Timer seinen nächsten Zeitpunkt an dem Punkt, an dem der Handler beendet wird, so dass die Zeit tatsächlich als Timer-Wert + Spiel-Up-Zeit erscheint. – Ian1971

+0

Es ist sicher nicht so, wie es in der Dokumentation heißt (und ich habe festgestellt, dass das in der Vergangenheit wahr war, als ich einen einfachen Maus-Tracker schrieb). Wenn es driftet, sollten Sie einen Fehlerbericht mit Apple einreichen. –

Antwort

4

Sie könnten versuchen, einen Thread zu erstellen und Ihren Timer in der Ausführungsschleife dieses Threads einzuplanen. Wenn dieser Timer als einzige Sache in dieser Laufschleife verwendet wird, sollte die Anzahl der Dinge, die ihn beeinträchtigen können, begrenzt werden.

Wenn das nicht funktioniert, werden Sie bereits einen Thread bearbeiten, also können Sie auch in eine usleep() - Schleife wechseln.

+0

Ich werde das versuchen.Es wird eine Weile dauern, bis ich wieder melden kann – Ian1971

+1

Ich endete mit [NSThread sleepForTimeInterval] und mach_absolute_time. Das Timing ist jetzt genau richtig. – Ian1971

5

Ich glaube nicht, dass NSTimer Ihnen "sehr" genaues Timing geben wird. Es wird in der Ausführungsschleife ausgelöst. Wenn es sich also in Ihrem Hauptthread befindet, wird es von UI-Aktualisierungen bis zur Ereignisbehandlung verzögert.

+0

Wenn ich sehr genau sage, ich meine, ich will nicht, dass es um mehr als 20ms driftet. Mein Timer feuert alle 44ms, wenn es abdriftet, möchte ich den nächsten Schuss korrigieren. In der Tat denke ich, ich werde die Frage mit dieser Info aktualisieren – Ian1971

+1

Das Dokument für NSTimer sagt, dass das Timing immer auf das ursprüngliche Intervall ab dem Zeitpunkt basiert, wenn es gestartet wird. Das heißt, es sollte nicht "driften", aber es kann "Jitter" haben. Das Dokument behauptet auch eine effektive Auflösung von 50 - 100 ms. –

+0

Hmm das ist wahrscheinlich keine genau genug Auflösung für mich. Ich habe es geschafft, die Varianz ziemlich zu reduzieren, indem ich das Feuerdatum basierend auf der Zeit seit dem letzten Feuer angepasst habe. Vielleicht muss ich in das von Peter Hosey erwähnte usleep() Timing schauen. – Ian1971

1

Denken Sie auch daran, dass die NSTimer Dokumentation heißt es:

Wegen der verschiedenen Eingangsquellen eine typische Laufschleife schafft, die effektive Auflösung des Zeit Intervall für einen Timer begrenzt ist auf die Reihenfolge von 50-100 Millisekunden. Wenn ein Timers Brennzeit auftritt, während die Laufschleife in einem Modus, der nicht Überwachung der Timer oder während einer langen callout ist, wird der Timer erst das nächste Mal die Laufschleife den Timer überprüft abzufeuern. Daher kann die tatsächliche Zeit bei , die der Timer möglicherweise auslöst, eine erhebliche Zeitspanne nach der geplanten Brennzeit sein.

Verwandte Themen