"Unglaubwürdigkeitsproblem" bei Frameratenberechnung

[Cpp_Junky]

Ich exportier die Framerate im Hintergrund in eine eigens dafür vorgesehene Oracle 10g Datenbank (Enterprise Edition). Nach Aufbereitung aller gemessenen Framerates kann ich anhand der FPS Schwankungen genaustens nachvollziehen, welche Taste der User gerade gedrückt haben muss, wo auf seiner Festplatte die Pornos liegen und wie hoch der Stromverbrauch von Castrop Rauxel um diese Uhrzeit war

[pock]

Cpp_Junky schrieb:

Ich würde GetTickCount verwenden, das lässt sich einfacher verwenden und frisst auch weniger Peformance als so ein hochauflösender Counter.

Ein Performance-Counter, den man normalweise einmal pro Frame ausliest, hat üblicherweise keinen relevanten Einfluss auf die Ausführungsgeschwindigkeit.
GetTickCount kann man verwenden, wenn man faul ist und nicht die tatsächliche Framerate wissen will, sondern ein ungefährer Richtwert ausreicht. Wenn man Pech hat, kriegt man immer nur Vielfache von 18.2 zu sehen.

[Cpp_Junky]

pock schrieb:

Ein Performance-Counter, den man normalweise einmal pro Frame ausliest, hat üblicherweise keinen relevanten Einfluss auf die Ausführungsgeschwindigkeit.
GetTickCount kann man verwenden, wenn man faul ist und nicht die tatsächliche Framerate wissen will, sondern ein ungefährer Richtwert ausreicht. Wenn man Pech hat, kriegt man immer nur Vielfache von 18.2 zu sehen.

Ich glaub ich hab das mal mit dem Visual Studio 6.0 Profiler gemessen und mich dann dafür entschieden keinen PerformanceCounter mehr zu verwenden. Die Genauigkeit von GetTickCount geht, hab das mal gegen den FPS Zähler in Fraps verglichen. Das unterscheidet sich um einige Frames, aber nicht der Rede Wert. Aber wenn man es ganz genau haben will ist das natürlich keine Lösung.

[dot]

rapso schrieb:

ich hab einen ringbuffer in dem ich die aktuelle zeit ablege und mit der zeit x-frames davor kann ich die durchschnitts framerate der letzten x-frames immer genau anzeigen. darauf schwoer ich seit jahrzaehnten

same

was GetTickCount() vs. PerformanceCounter angeht kann ich nicht oft genug auf diesen artikel verweisen

[pock]

Cpp_Junky schrieb:

Die Genauigkeit von GetTickCount geht, hab das mal gegen den FPS Zähler in Fraps verglichen. Das unterscheidet sich um einige Frames, aber nicht der Rede Wert. Aber wenn man es ganz genau haben will ist das natürlich keine Lösung.

Das ist vor allem dann keine Lösung, wenn man eine Zeitmessung vernünftigerweise an genau einer Stelle im Programm einmal pro Frame vornimmt und diese Messung für alle Timings des aktuellen Frames verwendet, also auch für die FPS-Anzeige.
GetTickCount hat im schlechtesten Fall eine Auflösung von 18.2 ms, was gerade bei Spielen oft nicht ausreicht.

[Cpp_Junky]

Gefährlich wird es erst dann, wenn die Framerate andere Komponenten beeinflusst und z.B. für Animationen herangezogen wird. Dann ist endgültig Schluss mit GetTickCount()

[pock]

Cpp_Junky schrieb:

Gefährlich wird es erst dann, wenn die Framerate andere Komponenten beeinflusst und z.B. für Animationen herangezogen wird. Dann ist endgültig Schluss mit GetTickCount()

Äh ja, genau das meinte ich, habs nur unglücklich formuliert.

[Don06]

Nochmal zum eigentlichen Beitrag:
Wenn du bei der Entwicklung deines Projekts noch nicht so weit bist (das Projekt ist noch nicht so komplex), kann es schnell zu sehr hohen Frameraten kommen. Ich habe mal ein kleines 2D Level mit Charaktern, Animationen, usw. gemacht.
Damals hatte ich eine Framerate zwischen 1000 und 2000 FPS.
Hast du so hohe Frameraten auch noch, wenn dein Projekt fast fertig ist, lohnt es sich VSync hinzuzuschalten. Dadurch wird der Tearing-Effekt (heißt glaub ich so) verringert, also das Flackern vom Bild. Allerdings wird dann die Framerate der Frequenz des Monitors angepasst: 100Hz -> 100 FPS

Gruß
Don06

[xindon]

hustbaer schrieb:

@xindon: üblicherweise macht man das nicht weil dann die angezeigte Framerate arg schwankt, manchmal so grob dass man eine einzelne Zahl nichtmehr ordentlich lesen kann. Ausserdem will man auch nicht unbedingt jedes Frame einen neuen Text rendern - je nachdem wie man den Text ausgibt kann das nämlich ganz schön lange dauern.

Besser wäre dann schon min/max/avg für eine Sekunde anzuzeigen, dann hat man wirklich brauchbare Werte, und kann sie auch in Ruhe lesen.

Aber, wie schon erwähnt, du hast dann ein Problem, wenn deine Bewegungen von der Geschwindigkeit abhängen. Wenn du die nur einmal in der Sekunde aktualisierst, kann's ganz schnell zu großen Sprüngen bzw. Slow-motion Bewegungen kommen, weil sich die Anzahl der zu rendernden Objekte zwischen zwei "FPS Aktualisierungen" drastisch ändern kann.

[Kahino]

Danke erstmal für die ganzen Antworten, wenn ich heute abend nach hause komme werde ich sie mir mal genauer anschauen, doch jetzt erstmal nähere Informationen.

Also dieser FPS-Berechnungstest ist unabhängig von meinem Spielprofjekt, ich wollte halt nur erarbeiten wie man sowas machen könnte.
Dafür habe ich mir mit Der Winapi ein einfaches Fenster erstellt in dem man mit den Pfeiltasten ein kleines weißes Quadrat über die Fensterfläche düsen lassen kann.
Die Spielschleife sieht dabei wie folgt aus:

while(msg.message != WM_QUIT)
{
     if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
     {
          TranslateMessage(&msg);
          DispatchMessage(&msg);
     }
     else
     {
      // Das ganze Zeug was so passiert
     }
}

Die Framerate berechne ich bis jetzt so wie ich es eigentlich auch beschrieben habe.
Dass die Framerate wirklich hoch sein muss, lässt sich dadurch zeigen, dass sich das weiße Quadrat nicht mehr im Fenster befindet wenn man auch nur kurz auf eine Pfeiltaste klickt.

Ich habe nun ein Paar Experimente gemacht um zu testen ob die Framerate ungefähr stimmen könnte, dafür habe ich zuerst versucht die Framerate durch Zeichenaufwand ein wenig zu drosseln.

Nachdem ich also um die 1500 Quadrate im Selbem Frame zeichnen lasse, beträgt die Framerate nur noch 129 FPS.
Der Wert war auch relativ konstant, nur kleine Ändrungen.

Dies heißt ja, bei einer nahezu konstanten Framerate von 129 FPS müsste sich das Quadrat in einer Sekunde um 129 Pixel bewegt haben (sofern es sich um einen Pixel pro Frame bewegt natürlich).
In zwei Sekunden um 258 Pixel, in drei Sekunden um 387 Pixel, in Vier Sekunden um 516 Pixel und in Fünf Sekunden um 645 Pixel.

Dieses Experiemt habe ich mehrmals durchgeführt.
Ich habe dieses Experiment sowohl vom Computer berechnen lassen als auch versucht die Zeit selbst zu stoppen (mit meiner Stoppuhr).

Mit Ausnahme kleinerer Abweichungen hat das auch alles gestimmt, doch wenn ich diese 1500 - 2000 Quadrate NICHT zeichne, habe ich eine durchschnittliche Framerate von 150 000FPS.
Zeichne ich ein ganzes Level und wechsel öfters die Stiftfarbe, Breite usw habe ich immer noch eine Framerate von 140 000 - 149 000.

Und eine solche Framerate kann doch nicht stimmen, deswegen verwirrt es mich, dass meine Experimente meine Framerate bestätigen.

[Don06]

Kahino schrieb:

150 000FPS

Ok, das ist mal was.
Ich dachte du hättest so um die 2000 FPS.
Da interessiert es mich doch, was die anderen Tests so ausspucken.

Gruß
Don06

[hustbaer]

xindon schrieb:

hustbaer schrieb:

@xindon: üblicherweise macht man das nicht weil dann die angezeigte Framerate arg schwankt, manchmal so grob dass man eine einzelne Zahl nichtmehr ordentlich lesen kann. Ausserdem will man auch nicht unbedingt jedes Frame einen neuen Text rendern - je nachdem wie man den Text ausgibt kann das nämlich ganz schön lange dauern.

Besser wäre dann schon min/max/avg für eine Sekunde anzuzeigen, dann hat man wirklich brauchbare Werte, und kann sie auch in Ruhe lesen.

Aber, wie schon erwähnt, du hast dann ein Problem, wenn deine Bewegungen von der Geschwindigkeit abhängen. Wenn du die nur einmal in der Sekunde aktualisierst, kann's ganz schnell zu großen Sprüngen bzw. Slow-motion Bewegungen kommen, weil sich die Anzahl der zu rendernden Objekte zwischen zwei "FPS Aktualisierungen" drastisch ändern kann.

Kein vernünftiger Mensch macht die Bewegung von irgendwas von der FRAMERATE abhängig, das macht man von der delta-time abhängig, und die misst man natürlich pro Frame. Ich weiss nicht was der Einwand soll ... ?!?

[rapso]

hustbaer schrieb:

und die misst man natürlich pro Frame. Ich weiss nicht was der Einwand soll ... ?!?

also wirklich vernuenftige menschen machen logic und rendering eh nicht voneinander mehr abhaengig als noetig also laeuft logic in logicframes ganz unabhaengig von der framerate

[xindon]

Aber wenn FPS ebenfalls von der delta time abhängen und jeden Frame aktualisiert werden, ist das doch wohl egal, wie man Geschwindigkeiten letztendlich berechnet

[rapso]

das hatten wir alles schonmal http://www.c-plusplus.net/forum/viewtopic-var-t-is-21275

[hustbaer]

@xindon:
Ich weiss immer noch nicht was der Einwand sollte. Wenn ich die Framerate will muss ich von der delta time ausgehen. Die kann ich messen, und dann wie ich lustig bin (gemittlet oder auch nicht) eine Framerate daraus berechnen.

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

[xindon]

hustbaer schrieb:

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

Inzwischen ist mir auch klar, was du willst und das es sinnvoller ist, aber ich möcht dir grad noch erklären, wie ich konstante Bewegungen realisiert hab.

Nehmen wir an, ich verteile meinen Figuren feste Geschwindigkeiten, die ich bei 60fps für richtig halte.
Wenn das Programm jetzt mit 90fps läuft, kann man ja mit deinen beiden Frameraten einen Faktor ausrechnen (60/90) und dann multipliziert man die Bewegungsgeschwindigkeit mit diesem Faktor...

[rapso]

xindon schrieb:

hustbaer schrieb:

Aber warum in aller Welt sollte ich wenn ich dann eben beides habe gerade die Framerate verwenden um irgendwelche Bewegungen zu steuern? Und schon garnicht wenn ich die Framerate gemittelt habe, die delta time aber noch "roh" ist?
Verstehe ich nicht wie man darauf kommen könnte das so zu machen. Klar wäre es Blödsinn, aber eben weil es so offensichtlich Blödsinn wäre verstehe ich den Hinweis darauf nicht...

Wenn das Programm jetzt mit 90fps läuft, kann man ja mit deinen beiden Frameraten einen Faktor ausrechnen (60/90) und dann multipliziert man die Bewegungsgeschwindigkeit mit diesem Faktor...

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

[xindon]

rapso schrieb:

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

Versteh ich jetzt nicht, was du damit meinst?

[rapso]

xindon schrieb:

rapso schrieb:

das heisst, je nach framerate werden sie verschiedene kurven laufen und verschieden oft "nachdenken"? *hehe*

Versteh ich jetzt nicht, was du damit meinst?

was daran faellt dir schwer zu verstehen?