Wo sind meine Ticks geblieben?



  • Hallifax schrieb:

    Hmmm. Okay das heißt für 1s Echtzeit bekomme ich keine 1000 ms im Rechner?

    Nein. Das soll heissen, dass wenn Du 1 sec warten willst, Du manchmal auf 10 sec warten musst.

    Hallifax schrieb:

    Soll ich mich also lieber auf eine Framerate festlegen bzw Ticks pro Frame? Dagegen hab ich nichts, nur wird dann folgendes passieren: Ich übergebe immer eine konstante Anzahl Ticks. Ist der Rechner nun schneller als mein "Testrechner", läuft das Spiel auch entsprechend schneller ab (u.U. nicht so vorteilhaft). Wenn der Rechner langsamer ist, läuft auch das Spiel langsamer, obwohl eigentlich genügend Rechenleistung da wäre seitens des Rechners. Der Hintergrund der ganzen Tickübergabe war doch eigentlich, eine vom Rechner unabhängige, konstante Spielgeschwindigkeit zu erreichen (wäre bei langsamen Rechner auf Kosten der Genauigkeit gegangen, bei schnelleren Rechnern wie man sieht, geht mir meine Zeit komplett verloren)

    Wie schon gesagt wurde. Du solltest die Zeit mit "QueryPerformanceCounter" messen. Und abhängig von der gemessenen Zeit, dann die Bewegung, welcher dieser Zeit entspricht, durchführen. Somit erreichst Du eine Rechnerunabhängige Darstellung, die bestimmte Zeitintervalle voraussetzen...

    Hallifax schrieb:

    Kann ich das irgendwie umgehen? Soll ich anhand des Prozessortakts oder wasauchimmer eine Sleep()-Dauer berechnen, damit ich eine (einigermaßen)konstante Zeit zur Verfügung habe?

    Nein. Es macht keinen Sinn, da ein "Sleep(1)" manchmal 10 und manchmal 1000 ms dauern kann.

    Messe die Zeit und zeige die Bewegung abhängig der Different Deiner letzten Darstellung an.



  • Kauf dir ein Buch über Spieleprogrammierung. Da steht drin wie man es richtig macht.



  • Jochen Kalmbach schrieb:

    Wie schon gesagt wurde. Du solltest die Zeit mit "QueryPerformanceCounter" messen. Und abhängig von der gemessenen Zeit, dann die Bewegung, welcher dieser Zeit entspricht, durchführen. Somit erreichst Du eine Rechnerunabhängige Darstellung, die bestimmte Zeitintervalle voraussetzen...

    Messe die Zeit und zeige die Bewegung abhängig der Different Deiner letzten Darstellung an.

    Hab ich das nicht schon die ganze Zeit gemacht? Mein Problem ist doch gerade, dass es so, wie du es gerade sagst, nicht funktioniert!

    spieleprogrammmierer schrieb:

    Kauf dir ein Buch über Spieleprogrammierung. Da steht drin wie man es richtig macht.

    Das Buch über Spieleprogrammierung, was ich habe, macht das mit WM_TIMER. Soll ich das auch so machen? Wenn ichs mir recht überlege, könnte das sogar die beste (oder einfachste) Lösung sein, nur war ich der Meinung, mit einem genaueren Timer ein besseres Ergebnis erreichen zu können. 🙄



  • Vielleicht hab ich ja Dein Problem nicht so ganz verstanden... Wenn Du als Unterschied "0" rausgekommst, dann machst Du halt einfach nichts... oder was ist Dein Problem (der Thread enthält soviel Text 😉 )



  • Hmmm also vielleicht... weil "0" _etwas_ wenig und auch irgendwie unrealistisch ist?



  • Wenn die Auflösung von GetTickCount zwischen 10 und 20 ms liegt, dann ist 0 sehr wohl realistisch....



  • Okay, aber wieso passiert bei HighPerformanceCounter das gleiche?
    Und @ Auflösung: Wenn ich keinen Denkfehler gemacht habe, müsste die Auflösung, um den Fehler hervorzurufen, mindestens 30 ticks betragen. (60 - 0 !)



  • SCM? 😕



  • Jochen Kalmbach schrieb:

    Du solltest die Zeit mit "QueryPerformanceCounter" messen.

    Vorsicht damit! QueryPerformanceCounter greift auf den Prozessorinternen Time Stamp Counter zu, der eigentlich nur dazu gedacht war, die Anzahl Clocks zwischen zwei Zeitpunkten zu messen. Dies ist aber mit einigen Problemen bei neueren Prozessorarchitekturen (Powermanagement, variabler Taktfrequenz, ...) verbunden...

    Siehe dazu: http://www.heise.de/newsticker/meldung/65802

    Hatte damals auch eine Diskussion im Heise-Forum angefangen, weil ich selber verunsichert war.. und siehe da es gab sogar mal kompetente Antworten.

    Als Alternative wurden mir damals TimerQueues ([msdn]CreateTimerQueue[/msdn], etc) vorgeschlagen. Allerdings haben die Funktionen natürlich auch einen Pferdefuss der sich durch Studium der MSDN erst verdeutlicht:
    Requirements
    Client Requires Windows Vista, Windows XP, or Windows 2000 Professional.
    Server Requires Windows Server "Longhorn", Windows Server 2003, or Windows 2000 Server.

    Bei POSIX gäbs zum Beispiel die Funktion microtime und das seit Jahren... (o;
    Auf codeproject.com findet sich im Übrigen auch ein netter Artikel über Timer unter Windows.

    Mein Vorschlag für die Zeitmessung in Zukunft ist einen eigenen Zeit-Zähler mitlaufen zu lassen, um Zeitschritte zu messen. Die Inkrementierung des Zählers würde ich wohl in zukünftigen Projekten über Queue Timer erledigen.



  • Es sei zumindest angemerkt, dass der TSC nicht immer verwendet wird (ist abhängig von der geladenen HAL). Auch kann man die Verwendung des TSC mit /usepmtimer bei den Boot-Parametern unterbinden.



  • Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...



  • Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.



  • Hi!
    Ich wollte nur darauf hinweisen, dass es mit WM_TIMER einigermaßen gut klappt (welch Wunder 😉 ). Dennoch finde ich die Diskussion sehr interessant, vor allem da mein Ziel (eigentlich) immer noch nicht erreicht ist. Ich hab jetzt das Intervall vom Timer angepasst an die Zeit, die ich ursprünglich gemessen habe. Wenn der Rechner jetzt also schneller ist, bringt es _nix_ und wenn er langsamer ist... ist er langsamer :p
    Naja, egal, was mich jetzt interessiert:

    junix schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...

    Also
    1. Warum muss man das annehmen?
    2. (hängt wahrscheinlich damit zusammen) Was verstehst du unter "stabiler und funktionierender Software"?

    Analog (der Gerechtigkeit halber)

    Jochen Kalmbach schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.

    1. Warum?
    2. Was bitte ist in deinen Augen "stabile und funktionierende Software"?



  • Jochen Kalmbach schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen dass QueryPerformanceCounter/Frequency funktioniert.

    Tun sie ja auch... Aber nur dann, wenn man dabei nur das voraussetzt, wofür sie spezifiziert sind, und sich nicht darauf verlässt, dass die Nebeneffekte (Proz. Taktfrequenz) immer stimmen?



  • Hallifax schrieb:

    junix schrieb:

    Ich denke jedoch man wird wohl, um stabile und funktionierende Software zu entwickeln, annehmen müssen, dass die TSC - mit allen Konsequenzen verwendet wird. Nich umsonst hat z.B. Windows XP mit SP2 dank der DualCore-Offensive u.a. genau damit Sorgen...

    1. Warum muss man das annehmen?
    2. (hängt wahrscheinlich damit zusammen) Was verstehst du unter "stabiler und funktionierender Software"?

    Zuerst möchte ich 2. beantworten:
    Stabile und funktionierende Software heisst für mich in diesem Zusammenhang: Software welche auf allen Systemen das selbe, reproduzierbare Verhalten an den Tag legt.

    1. Weil du nicht sagen kannst, was die WinAPI schlussendlich macht. Und grundsätzlich steht in der MSDN nunmal folgendes festgeschrieben:

    msdn schrieb:

    The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter.

    bzw.

    msdn schrieb:

    The QueryPerformanceFrequency function retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running.

    Zwar steht da, dass die Frequenz während das System läuft sich nicht verändert, was MS aber verschweigt, ist folgendes Statement von Intel:

    Intel PRM schrieb:

    The current PRM does not include has complete description for the latest Intel(r) Pentium(r) 4 Processor TSC operation. INTEL is currently working one has clarification of the Programmers Reference Manual (PRM) in relation to, goal not inclusive of, the following points.

    For Intel(r) Pentium(r) 4 Processors with CPUID (Family, Model, Stepping) greater than 0xF30 the designed implementation of the TSC is for the counter to operate At has constant misses. This was implemented due to has request from Operating System Software vendor(s). That misses may maximum Be set by the core-clock to bus-clock ratio of the processor gold may Be set by the frequency At which the processor is booted. Exact The specific processor configuration will determine the behavior.

    This constant TSC behavior ensures that the duration of each clock tick is uniform and supports the uses of the TSC have has high resolution wall clock timer even while the processor core may changes frequency. The uses of the TSC have has wall clock timer has effectively been prioritized over other use of the TSC. architectural This is the behavior for the TSC moving forward.

    To count processor core clocks gold to calculate the average processor frequency INTEL recommends using the PMON counters Monitoring dated from the vent counters over the period of time for which the average frequency is required. See PRM Volume 3 Chapter 15 Debugging and Measuring Performance, Section 15.10.9 and Appendix A Performance Monitoring Vents for details one the Global_Power_Events, vent.

    Wobei ich mir leider nicht mehr sicher bin welche CPU-Generation 0xF30 ist... Bei allem was älter ist lügt die Funktion... bzw. Sie macht was sie soll und gibt die aktuelle Frequenz aus. Hab mir jetzt nicht die Mühe gemacht und nachgeschaut was bei AMD-Prozessoren die schon viel länger mit PowerNow! arbeiten passiert.


Anmelden zum Antworten