Ich bin mir nicht sicher, ob es tatsächlich ein Problem ist oder ich mir zu viele Sorgen machen.
Ich habe zwei kleine Demos geschrieben, um zu sehen, wie viel FPS ich tatsächlich mit SDL (mit OpenGL und ohne) herausbekomme. Nach einigen Tests mit meinen Computern und den PCs von einigen Freunden sind mir einige merkwürdige Phänomene aufgefallen.
Beabsichtigt war, dass die FPS sofort bestimmt werden, und nicht von null an hochgezählt wird. Das funktionniert anscheinend nur auf einigen PCs. Merkwürdig auch, dass bei der Demo, bei dem das Quad gezeichnet wird, auf einem meiner Computer (500 MHz; 128 MB RAM; ATI Rage Pro mit 8 MB Grafikspeicher) unzulässige FPS - Werte angezeigt werden (wie 0, 2, 4 oder auch 1000 FPS). Die Anwendung läuft aber dennoch recht schnell (es ist bei der Quad - Demo möglich, sich mit den Pfeiltasten um den Quad zu drehen).

Meine FPS - Berechnung sieht folgendermaßen aus:



Hab ich mit der FPS - Berechnung geschlampt oder ist mein "Problem" normal? Ich habe die Demos als Anhang hinzugefügt, damit man sich ein Bild von der Sache machen kann.

P.S.: Die Window - Demo ist nicht OpenGL-beschleunigt, deshalb ist es in Ordnung, wenn die Quad - Demo mehr FPS hat. Die SDL - DLLs sind in der RAR - Datei nicht mitgeliefert.

_________________
[http://www.freeze-dev.de]

Also deine Berechnung ist ein Framecounter welcher dir die durchschnittliche Framerate über die gesamte Zeit ermittelt (falls vorher kein überlauf eintritt).

Wenn du einfach nur die Frames/Sek berechnen willst, solltest du immer die aktuelle Zeit bestimmen, und wenn die Differenz zur startzeit >=1 Sec ist, die Frames ausgeben, dann auf 0 setzen und startzeit = aktzeit setzen. Dann hast du immer die Frames pro Sekunde.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

so einfach ist das
Gruß
Jan

Ja gut. Der Verweis aufs Wiki war obligatorisch:

http://wiki.delphigl.com/index.php/Framecounter

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wieso wird da eigentlich nur die zeit fürs rendern genommen? Rein theoretisch kann ja außerhalb des Renderns Zeit verbraten werden. Wenn das mehr als Bruchteile wären dürfte dies das Flussverhalten (Timebased Movement) empfindlich stören. Also ich bin der Meinung, dass man nur einmal pro Frame zeit messen sollte und das sich der Zeitraum für ein Frame bis zum nächsten definierten Punkt erstrecken sollte.

Wobei es beim OnIdle, wenn das Fenster in der Größe verändert wird, dann zu einem Stillstand kommt was sich in extrem großen Sprungen im Movement äußert. Was eigentlich wieder dafür sprechen würde es so zu lassen wie es ist. Auch wenn das mitunter rechnerrisch nicht die richtigste Lösung wäre.

Ich denke, diese Eigenart stammt u.A. aus dem Bomberman-Tutorial. Dort misst Sascha ja auch nur die Zeit, die zum Rendern benötigt wird.

Doch gerade bei Netzwerk-Geschichten fällt es durchaus auf, wenn man lediglich die Renderzeit in das Timebased Movement einrechnet. Da ist es dann doch wesentlich besser und genauer, wenn man einmal pro Frame die Zeit abgreift und dadurch die tatsächlichen fps erhält

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Noch krasser sind Framecounter, welche anhand eines Renderdurchganges berechnen wieviele sie in einer Sekunde geschafft hätten(!). Die bilden dann immer einnen Mittelwert über diese Werte, für die letzten x durchläufe. Da kommen dann selbst auf meiner Intel OnBoard Graka Astronomische Werte raus.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Vielen Dank für die Hilfe! Ich habe es jetzt hinbekommen

_________________
[http://www.freeze-dev.de]