Wenn eine reine FPS-Anzeige gebraucht wird ist der Code richtig
"gezeichnete Frames" = FPSZ

Die Funktion wird pro Renderdurchgang (nach dem Renderauftruf) ausgeführt - zählt FPSZ hoch - bis Rate erreicht ist -> "Rate"-Frames (also 20) in gemessener Zeit...

... wenn da ein Denkfehler drin ist - ich lasse mich gern belehren

Auf die Gefahr hin, dass ich mich jetzt komplett blamiere (vorausgesetzt der FPS-Counter ist wirklich falsch):
-> Timebased Movement

Entscheidend ist hier die vergangene Zeit, seitdem das sich bewegende Objekt zuletzt gezeichnet wurde, also (Ende - Start)



Ist also prinzipiell richtig... (aus der Wiki ?)

Frequenz hat dabei zwei mögliche Funktionen, je nachdem, wie Start / Ende ermittelt wird:

Verwendet man getTicks ist Frequenz nur der Umrechnungsfaktor 1000 für ms -> Sekunden.
Im anderen Fall (QueryPerformanceCounter) bekommt man ja eine Anzahl der Takte seit Computer- bzw. Programm-Start oso und
errechnet mit der ermittelten Frequenz (QueryPerformanceFrequency) (1/s) die Zeit. (in s)

Beim Timebased Movement musst du genauso wie bei den FPS die Zeitdifferenz messen. Also immer von einem Start des Frames bis zum Nächsten. Wenn in der Renderfunktion nichts gezeichnet wird, würde auch die Differenz Null sein und die simulierte Zeit würde still stehen. Das wäre so als ob man die Augen schließt und so die Zeit anhalten kann. Was meiner Erfahrung nach aber nicht funktioniert.

Ich habe diesen Thread jetzt nur halb verfolgt, aber ich mische mich trotzdem kurz ein

Du solltest nicht die Zeit messen die dein Aufruf von Render() braucht. Das drumherum, das Betriebssystem usw. braucht ebenfalls Zeit! Was du wahrscheinlich haben willst ist die Dauer eines Frames. D.h. du musst die Zeit messen die vergeht bis du an der selben Stelle des Codes (*) wieder ankommst.

Also etwa so:



(*) z.B. der Stelle vor dem Aufruf von Render(), damit du die gemessene Zeit direkt an Render() weitergeben kannst.

_________________
Yeah!

ah thx.


Habe den Code nur mal getestet und anhand den Tuts hier muss die frequenz ausgelesen werden. Verwende mal nicht 20 sondern 30 oder so.

Und mit wglSwapIntervalEXT(1) kannst du deine FPS Anzeige prüfen.
Steht hier direkt am Anfang vom Thema. Dann sollten 60 FPS raus kommen, das hatte ich bei dir nicht, deswegen die Vermutung das es so nicht stimmen kann.....

Ich kann (momentan) nur unter Linux testen, kann also wglSwapIntervalEXT(1) nicht benutzen, das Linux-Äquivalent ist etwas komplizierter...

Auf jeden Fall kommt die gleiche FPS raus, egal welchen Wert ich für Rate verwende (mit 1 und 30 getestet...)

Und: Ich verwende SDL_getTicks : bekomme also Millisekunden - keine Notwendigkeit für Frequenz, die braucht man ja nur für die Umrechnung

Delta_PerformanceTicks / Frequenz = vergangene Zeit
(blöderweise nennt die Wiki den Faktor 1000 für die Umrechnung ms -> Sekunden auch "Frequenz"...)

Um die FPS mit "QueryPerformance..." zu bekommen:

FPS = Delta_PerformanceTicks / Frequenz * Rate

...und das müsste mit den Lösungen hier und der Wiki übereinstimmen.

Wichtig (wurde auch schon angemerkt, trotzdem:)
Immer die ganze Zeit zwischen zwei Renderaufrufen bzw. "BufferSwaps"
messen. Spätestens bei größeren Projekten braucht Spiellogik, Physik, KI, etc. eine beträchtliche Rechenzeit und die FPS-Zahl wäre viel zu groß...

Ist gewissermaßen korrekt. Wenn man nicht von ms ausgeht sondern von „Ticks“, dann ist 1000 Hz = 1000 Ticks pro Sekunde der korrekte Umrechnungsfaktor.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

OK, akzeptiert

Kann aber auch (unnötigerweise?) Verwirrung stiften, ein Hinweis im Wiki wäre da hilfreich
(darf ich noch nicht editieren... )

EDIT: Bezogen auf http://wiki.delphigl.com/index.php/Timebased_Movement