Frametime vs FPS

Ich gehe über "File"->"import"->"single ASCII"
und dann habe ich es korrekt drin....aber es kann sein, dass ich den standardimport irgendwann mal geändert habe. ;)
Ergänzung ()

...guck mal unter Tools-> options-> numeric Format, was er da als "Seperators for ASCII import" drin hat.
Ergänzung ()

meins steht auf 1,000.0
 
Zuletzt bearbeitet:
"Windows Settings"

Mal alle durchgegangen, sowohl "1 000.0" als auch "1,000.0" habens gebracht. Jetzt passt alles, danke^^
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Wenn du die Files mit 1-3 oder 1-5 Messungen importierst, musst du natürlich die richtigen Spalten als X markieren.....hat mich recht lange gekostet, bis ich herausgefunden hatte, dass man auch alle anwählen kann und dann XYYY XYYY auswählt und sofort jede vierte als X hat......aber vermutlich hast du das schon gewusst^^.
Man kann auch irgendwo den Standardimport ändern, damit er das gleich so macht, aber das habe ich nicht mehr drin, und habe auch vergessen wie^^
 
@Baal Netbeck Und schon stoße ich auf ein Problem, welches in Zukunft wohl sehr viel häufiger vorkommen wird: Fraps funktioniert scheinbar nicht in DX12.

Wollte gerade mal Tomb Raider benchen und die Anzeige taucht nicht auf. Auch das Drücken des Benchmark Hotkeys hat keine Funktion. In den Optionen auf DX11 gestellt und die Anzeige ist wieder da.

Sucht man nach einer Lösung, kommt eigentlich nur "Das Programm wird seit 5 Jahren nicht mehr supportet, nimm halt Afterburner "
 
...Vulkan habe ich gar nicht mit Fraps zum laufen bekommen, aber meine DX12 Spiele habe ich auf Umwegen zum laufen bekommen.
Bei Rise of the Tomb Raider war der Trick erst ohne Fraps zu starten. Dann das Spiel minimieren....Fraps starten....Fraps minimieren....wieder ins Spiel und jetzt(wichtig) den exklusiven Vollbildmodus aktivieren.
Der deaktiviert sich auch automatisch beim minimieren, muss also neu ausgewählt werden.
Dann kann man die Benchmarks machen, aber das Overlay wird man nicht zu gesicht bekommen.....man bencht praktisch "blind".....wobei ich nicht ganz blind bin, weil ich den Ordner wo die Ergebnisse gespeicher werden am zweiten Monitor offen habe, so sehe ich ob die Messungen erscheinen ohne minimieren zu müssen(und wieder den exklusiven Vollbildmodus zu aktivieren).
 
Man findet auch dutzende News, dass die Entwickler DX12 und Vulkan Support einbauen werden mit Version 3.6.0, nur die News sind alle aus 2016 und die neuste Version ist heute immer noch 3.5.99 von 2013.
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Ja leider......ich habe es gerade in Shadow of the Tomb Raider ausprobiert.....hier kann man Fraps sogar vorher schon offen haben.
Nur den exklusiven Vollbildmodus wird man wohl brauchen.....ich teste mal ob die Frametimes korrekt gemessen werden.....
 
Baal Netbeck schrieb:
wobei ich nicht ganz blind bin, weil ich den Ordner wo die Ergebnisse gespeicher werden am zweiten Monitor offen habe, so sehe ich ob die Messungen erscheinen ohne minimieren zu müssen(und wieder den exklusiven Vollbildmodus zu aktivieren).
Den Trick habe ich auch versucht, jedoch erscheint die Datei bei mir erst nach dem Beenden den Benches.
 
ich habe mit dem MSI Afterburner gegengetestet....der Sagte einen Durchschnitt von 84,8 FPS und Fraps 84,83.
Also ziemlich perfekt.
Frametimes passen wieder nicht, aber MSI sagt der schlechteste wäre 18,3FPS gewesen und mein Auswertungsprogramm sagt es gab keine Frames unter 15 und zwei unter 20 gab.....das passt also.
Ergänzung ()

Taxxor schrieb:
Den Trick habe ich auch versucht, jedoch erscheint die Datei bei mir erst nach dem Beenden den Benches.
Das ist ja immer so......erst beim beenden wird die Datei erstellt.
 
Ist natürlich blöd wenn man auch außerhalb des Benches seine FPS sehen möchte, das geht dann bei Tomb Raider wieder nur über den Afterburner, also müssen beide laufen.

Wie kommen denn die Tech Seiten an ihre Frametimes?

Baal Netbeck schrieb:
Das ist ja immer so......erst beim beenden wird die Datei erstellt.
Ich kenn es auch so, dass die Datei erstellt wird und man live beobachten kann wie sie größer wird.
 
Zuletzt bearbeitet:
Taxxor schrieb:
Ich kenn es auch so, dass die Datei erstellt wird und man live beobachten kann wie sie größer wird.
Komisch...ist bei mir noch nicht passiert....aber kann sein, dass wir andere Versionen nutzen.

Ich denke die Techseiten nutzen inzwischen fast alle Presentmon oder ähnliches.....oder den Afterburner.
Aber Presentmon hat mich mit dem Einlesen der Frametimes überfordert.

Mein Programm ist eigentlich reine Fleisarbeit....alles mit sehr einfachen Mitteln erstellt und mit Presentmon war nicht einfach die Zeit ab Start der Messung drin, sondern ein ganzer Haufen Spalten....die zweite Spalte in Fraps einzulesen habe ich mit google hinbekommen. Die X. habe ich nicht geschafft. ;)
Und es war mir auch zu blöd, weil es so kompliziert zu nutzen war....entweder man musste die .exe vorher angeben, und mit Konsolenbefehlen rumhantieren, oder man hatte diese "anwenderfreundlicheren" Versionene, die aber nur in der Hälfte meiner Spiele den Benchmark-Hotkey erkannt haben oder überhaupt das Game erkannt haben.

Ich nehme an inzwischen ist es besser geworden, aber da ich mit Fraps bis jetzt nur in Vulkan probleme hatte, bin ich dabei geblieben.
 
Die Berechnungen bei Afterburner stimmen. Unwinder (Entwickler) hat das im Thread erklärt. Auf der Seite hat er das noch weiter erklärt und ich hab es auch mit anderen getestet. 1000 ms runterstellen auf das niedrigste und der Min Wert wird immer als niedrigster angezeigt.
 

Anhänge

  • 2.jpg
    2.jpg
    151,9 KB · Aufrufe: 393
MitchRapp schrieb:
Die Berechnungen bei Afterburner stimmen.
Er sagt die schlechtesten Frametimes werden für die letzten 30min bei 60FPS gezählt.
Das heist ja noch nicht, dass sie richtig berechnet werden.
In den drei Spielen, die ich getestet habe, haben sie nicht gestimmt.
Werden also falsch berechnet und sind damit unsinnig.

Die min und max FPS scheinen ganz gut zu stimmen. Hat man auf 1000ms gestellt, dann passen sie zu der erwarteten schlechtesten vollen Sekunde.
Stellt man im Rivatuner auf instantanious, entspricht der min FPS Wert dem schlechtesten Frametime.
Der Max Wert stimmt nicht ganz, ist aber relativ nah am besten Frametime Wert.

Alles in allem eher ein schlechtes Zeugnis.

Auf wass soll ich die 1000ms im Afterburner denn stellen? auf 300? auf 100? Und was sagt mir das dann aus?
MitchRapp schrieb:
1000 ms runterstellen auf das niedrigste und der Min Wert wird immer als niedrigster angezeigt.
Da verstehe ich den Satz nicht.
 
Ich habe dann nochmal nachgeguckt, was diese
Baal Netbeck schrieb:
"anwenderfreundlicheren" Versionen
von Presentmon waren.
Die beste scheint OCAT zu sein. Da bekommt man auch ein Overlay im Spiel und man kann die spiele.exe über den Explorer suchen, anstatt den Pfad in die Konsoleneingabe schreiben zu müssen.

Ich hatte sogar noch die alte Version auf dem Laptop, aber damit ließ sich z.B. Ashes Of the Singularity nicht messen. Und auch ein paar andere Spiele nicht, weil man nicht einfach das Spiel starten konnte sondern mit dem Programm die Spiel.exe.
Da sich in Aots erstmal ein Launcherfenster mit der gleichen ProzessID öffnet, bindet sich das Overlay nicht ein und es wird nichts gemessen.

Aber die neuste Version von GitHub geht:
So sehen die Rohdaten aus:
vergleich Fraps OCAT AotS rohdaten.PNG

Mit Fraps muss man die Einzelnen Frametimes noch aus den Zeiten ausrechnen,
OCAT(PresentMon) macht das schon für einen.....und es nimmt eine Reihe weiterer Werte auf, wo ich nicht sicher bin, was diese sein sollen.

Auch hat Fraps schon 71ms lang Frames aufgezeichnet, bis OCAT anfängt zu zählen und reagiert einen Frame(in dem Fall 14,5ms) später auf das beenden der Messung.
Das ist nicht weiter schlimm, bedeutet aber , dass ich die eine Messung verschieben musste, damit sie übereinander passen:
vergleich Fraps OCAT AotS graph.png


Bis auf Ausnahmen passen die Frametimes zusammen. Was diese MsUntilDisplayed sind, hab ich noch nicht gesucht....sie aber einfach mal mit aufgetragen.

Hier sind die Ergebnisse der Statistik.....einmal die Fraps Messung mit meinem Programm ausgewertet. Dann die OCAT Messung in das Fraps Format umgeschrieben und mit meinem Programm ausgewertet.
und darunter die Statistik, die OCAT selbst ausspuckt.....ich habe mal die avg Frametimes und die 99th Percentile markiert:
vergleich Fraps OCAT AotS stats.PNG
 
Zuletzt bearbeitet:
@Baal Netbeck Ich würde immer noch gerne herausfinden, wie genau MSI diese Werte berechnet. Ich habe gerade mal No Mans Sky getestet und zwar extra direkt zum Start, wo diverse heftige Nachladeruckler auftreten.

So sehen die Frametimes aus
nms.jpg


Der Wert bei 20s geht bis 1400ms hoch.



Das sagt MSI

03-12-2018, 16:07:18 NMS.exe benchmark completed, 3958 frames rendered in 80.516 s
Average framerate : 49.1 FPS
Minimum framerate : 0.7 FPS
Maximum framerate : 75.3 FPS
1% low framerate : 0.7 FPS
0.1% low framerate : 0.7 FPS



Das sagt FRAPS

klassischer Durchschnitt 49.2
avg 1% low 6.684
avg 0.1% low 1.604


Bisher war es bei deinen Vergleichen und auch meinen eigenen danach gemachten Vergleichen eigentlich immer so, dass die 1% low Werte von MSI höher asugefallen sind, als die korrekten 1% low. Daraus hätte man ja ein Muster ableiten können, hier ist es aber genau anders rum.
Ergänzung ()

Baal Netbeck schrieb:
Dann die OCAT Messung in das Fraps Format umgeschrieben und mit meinem Programm ausgewertet.
War das arg aufwendig? Wenn nicht, könnte man OCAT ja als FRAPS Ersatz nehmen und dein Tool weiter nutzen und würde so das DX12+Vulkan Problem lösen ohne großartigen Mehraufwand.
Ich bezweifle nämlich irgendwie dass von Beepa noch was kommt, wenn man seit der Ankündigung mit dem Kommentar "coming soon" 2 Jahre nichts mehr von ihnen gehört hat.
Und DX12 Games werden in den nächsten Jahren tendenziell sehr viel mehr werden, alleine schon durch Nvidias neuen Fokus auf DX12.


Habe mir jetzt auch mal die neuste OCAT Version von github geladen.
Bei Shadow of the Tomb Raider erscheint das Overlay auch ganz automatisch(welches sehr schick ist), nur passen die Werte, die er in die csv dateien schreibt, so ganz und gar nicht zusammen.

Ich habe zum Test mal nur im Menü für 10sek gebencht, die fps waren laut overlay fast konstant bei 110.
Nach dem Beenden des Benches zeigt das Overlay ja auch kurz ein paar Ergebnisse an.
Dort stand
average FPS 109,7
average ms 9,1

Passst also soweit, in der perf_summary steht aber nun

Application Name SOTTR.exe
Average FPS (Application) 55,2373
Average frame time (ms) (Application) 18,1037

Nochmal direkt im Spiel getestet, Overlay sagt nach dem Bench 89,5fps avg, die Summary sagt 44,6259.
Auffällig dabei ist, dass die Werte ziemlich genau halbiert sind.

Starte ich das Spiel in DX11, sind es im Menü nur 65fps, die protokollierten Werte passen dann aber zusammen, bei DX12 sieht es so aus wie oben.

Edit: Bei Battlefront 2 passen die Werte auch in DX12

Edit 2: Die ausgelesenen Daten sind bei Tomb Raider in beiden Fällen korrekt, habe gerade mit FRAPS noch mal gleichzeitig in DX12 im Menü gebencht, der sagt mir 54,2fps avg, OCAT sagt 54,16fps.
Es ist hier also nicht der Benchmark, der nur die Hälfte der fps aufnimmt, sondern das Overlay, was die doppelte Framerate anzeigt. Habe das mal auf github gemeldet.

Ich glaube langsam es gibt kein einziges Tool, welches überall ordentlich funktioniert... aber wenigstens stimmen die Werte die man aufnimmt.
Ergänzung ()

Baal Netbeck schrieb:
Auf was soll ich die 1000ms im Afterburner denn stellen? auf 300? auf 100? Und was sagt mir das dann aus?

Da verstehe ich den Satz nicht.
Ich denke er meint das "Framerate averaging interval" im RivaTuner, das kann man auf 0 stellen, hat aber im Prinzip den gleichen Effekt wie das umstellen von average auf instantaneous weiter unten.
Zumindest stand es bei mir in der NMS Messung auf average und oben auf 10ms und dadurch ist der min Wert der schlechteste Frame.
Lässt man es auf 1000ms und stellt unten auf instantaneous, passiert meinen Beobachtungen nach das gleiche.

Ich habe auch mal in den Einstellungen vom Afterburner den "Hardware Abfragezeitraum" von 100ms auf das niedrigste (100ms) gestellt, das hat aber überhaupt keinen Unterschied gemacht, bzw. die Werte weichen nach wie vor stark von FRAPS ab.
 
Zuletzt bearbeitet:
OCAT scheint die Frametimes aber auch nicht so zu erfassen, wie FRAPS und damit habe ich vielleicht auf die Erklärung, wie MSI auf die low Werte kommt.

Hier mal ein Auszug der letzten Frametimes aus einer Messung von Kindome Come
Links: OCAT, Rechts: FRAPS
ft.jpg

Bei FRAPS sieht man zwischendrin Schwankungen 13 zu 19ms. OCAT geht an diesen Stellen ebenfalls hoch bzw. runter, bleibt aber insgesamt immer zwischen 16-17ms.

Die avg frametimes sind mit 16,3786 zu 16,3754 am Ende lustigerweise aber nahezu identisch, somit auch die avg fps.

Die 99 Percentil frametimes gehen mit 21,4433 zu 23,45 allerdings schon ziemlich auseinander, was 46,64fps laut OCAT und 42,65fps laut FRAPS bedeutet.


Hier habe ich eine Erklärung gefunden
There's a pretty widespread assumption at other sites that FCAT data is "better" since it comes from later in the frame production process, and some folks like to say Fraps is less "accurate" as a result. I dispute those notions. Fraps and FCAT are both accurate for what they measure; they just measure different points in the frame production process.

It's quite possible that Fraps data is a better indication of animation smoothness than FCAT data. For instance, a smooth line in an FCAT frame time distribution wouldn't lead to smooth animation if the game engine's internal simulation timing doesn't match well with how frames are being delivered to the display. The simulation's timing determines the *content* of the frames being produced, and you must match the sim timing to the display timing to produce optimally fluid animation. Even "perfect" delivery of the frames to the display will look awful if the visual information in those frames is out of sync.

What we do now for single-GPU reviews is use Fraps data (or in-engine data for a few games) and filter the Fraps results with a three-frame moving average. This filter accounts for the effects of the three-frame submission queue in Direct3D, which can allow games to tolerate some amount of "slop" in frame submission timing. With this filter applied, any big spikes you see in the frame time distribution are likely to carry through to the display and show up in FCAT data. In fact, this filtered Fraps data generally looks almost identical to FCAT results for single-GPU configs. I'm confident it's as good as FCAT data for single-GPU testing.
https://techreport.com/blog/28679/is-fcat-more-accurate-than-fraps-for-frame-time-measurements

Und dazu passt auch ganz gut, dass ich mir gerade noch mal die FRAPS Ausgabe Datei angesehen habe, und die berechnete "local avg ft" passt ziemlich genau zu dem, was OCAT angibt.

Das gleiche könnte auch der Afterburner machen, der kam ja auch meist auf etwas höhere 1% low Werte als FRAPS. Das teste ich gerade mal mit Kingdome Come aus.

Nur komisch, dass bei deinem AotS Bench dan aber die Frametimes der beiden gleich sind.
 
Zuletzt bearbeitet:
Taxxor schrieb:
Ich würde immer noch gerne herausfinden, wie genau MSI diese Werte berechnet.
Ich auch....Die Sache ist natürlich auch, dass man nicht sagen kann, MSI berechnet es "falsch", denn die X% low Frametimes sind nicht wie die Percentile Werte festgelegte Größen aus der Statistik.

Das ist soweit, ich weiß, von ein paar Tech-Youtubern verbreitet worden.
Hardware unboxed und Gamers Nexus nutzen beide das gleiche System, auf das auch ich mich beziehe....also der Mittelwert aus den schlechtesten Frametimes aller Frametimes einer Messung.

MSI scheint das anders zu handhaben. Hier gibt z.B. die Aussage des Entwicklers Hinweise(die MitchRapp verlinkt hat) Hinweise.

Es wird offenbar für die schlechtesten Frametimes ein Speicher von 1024 Frametimes bereitgehalten.
Mit üblichen Messzeiten sollte es hier also keine Probleme geben.

Da nichts über einen Gesamtspeicher gesagt wird, nehme ich an, das es den nicht gibt, und er wäre für die Berechnung ja auch nicht nötig.
Es muss nur die Benchmarkdauer und die Anzahl der Frames aufgezeichnet werden.
Und kurzfristig die Frames der letzten Sekunde, wenn die min/max Werte auf eine Sekunde bezogen ermittelt werden sollen.

Was nötig wäre, wäre die neuen Frametimes pausenlos in die Liste mit den schlechtesten Frametimes einzusortieren.
Es müsste also immer eine sortierte Liste geben und diese muss mit jedem Frame(der lang genug war) ergänzt werden.
Nach 17s mit 60 FPS wäre der Speicher voll und darin sehe ich jetzt kein Problem.
Aber was mich verwirrt hat ist die aktualisierungsrate.
Ich sehe ein, das die min/max Werte sich verändern, wenn man im Rivatuner auf instantan stellt. Das ist aber meiner Meinung nach nicht das was man sehen sollte und nicht das was vom Entwickler gewünscht wird, sonst wäre es standardmäßig anders.
ist es auf average, und der Afterburner auf 1000ms, dann kommt ja auch das gleiche raus was Fraps ausgibt und ich denke das war so gewollt.

Die 1% und 0.1% low scheinen sich von den Änderungen nicht beeindrucken zu lassen und das ist ja auch gut so.

Aber ihre Aktualisierungsrate gibt mir Rätsel auf.
direkt nach starten der Messung ändern sich die Werte(min/may und 1%/0.1% low) sehr schnell(unter einer Sekunde) dann ändern sich die Werte immer seltener.
Die Min/Max Werte ändern sich ab da nur noch wenn es noch niedrigere oder noch höhere Werte gibt,
aber ich hätte erwartet, dass die low Frametimes einfach in regelmäßigen Abständen aktualisiert werden und sich dabei pausenlos ändern.
Denn das müsst eigentlich passieren.....es werden pausenlos mehr Frames, das bedeutet, dass zumindest bei den 1% low sehr häufig ein weiterer Frame zu der Berechnung der 1% low hinzugenommen werden muss, auch wenn keine schlechteren einsortiert wurden.
Damit sollte der Wert eigentlich pausenlos besser werden, bis wieder Frametimepeaks ihn nach unten hauen und dann sollte er sich wieder Schritt für Schritt erholen.
Das passiert aber irgendwie nicht.

Sobald schlechte Framtimes dabei sind, wird der Wert sofort nach unten gehauen, aber manchmal ändert er sich dann für lange Zeit nicht.(habe es als Video aufgenommen)

z.B. nimmt der 0.1% low Wert 11s nachdem ich eine Messung gestartet habe 25.2FPS an.
Der Durchschnitt wird zu diesem Zeitpunkt mit 85,2FPS angegeben, es hat also ca. 937 Frames gegeben.
Das ist also der schlechteste Frame und das sollte so bleiben, bis ein noch schlechterer kommt oder es 2000Frames werden.
Ab da sind die FPS eher um die 80, was bedeuten würde, dass 1000 neue Frames schon nach 13s erreicht sein sollten.
Wenn der Wert bis da hin nicht niedriger geworden ist, gab es keinen schlechteren Frame und der Wert sollte als Durchschnitt mit dem zweiten Frame besser werden.
Wird er aber nicht, sondern ändert sich erst nach 28s(39s nach Start der Messung)Auf 26,2. Hier sollte eigentlich schon ein dritter Frame in die Berechnung mit einbezogen werden.
Die 26,2 blieben dann sogar weitere 38s gleich(bis ich die Messung beendet habe)
In dieser Zeit hätte sich der Wert 2-3Mal aktualisieren müssen.

Taxxor schrieb:
OCAT scheint die Frametimes aber auch nicht so zu erfassen, wie FRAPS.
gucke ich mir gleich mal an....
Ergänzung ()

Taxxor schrieb:
Bei FRAPS sieht man zwischendrin Schwankungen 13 zu 19ms. OCAT geht an diesen Stellen ebenfalls hoch bzw. runter, bleibt aber insgesamt immer zwischen 16-17ms
Hast du die Frametimes mal aufgetragen?
Bei mir hatte sich dann gezeigt, dass die zu unterschiedlichen Zeitpunkten angefangen haben zu messen(obwohl es der gleiche Hotkey war) und daher zueinander verschoben werden mussten.
Bei dem vielen Auf und Ab sieht man das natrülich erst im Graph.
 
Zuletzt bearbeitet:
Baal Netbeck schrieb:
Hast du die Frametimes mal aufgetragen?
Bei mir hatte sich dann gezeigt, dass die zu unterschiedlichen Zeitpunkten angefangen haben zu messen(obwohl es der gleiche Hotkey war) und daher zueinander verschoben werden mussten.
Bei dem vielen Auf und Ab sieht man das natrülich erst im Graph.

Also ich habe mir das grob über 200 Frames angeschaut, die OCAT Werte gehen wirklich selten mehr als 2ms auseinander, während die FRAPS Werte(auch in den Bereichen 50 Frames drüber und drunter versetzt) 4-6ms schwanken.


So gerade Kindom Come gemessen und mal die 1% low der local avg frametimes ausgewertet.

MSI 1% low: 50,0
FRAPS Local avg 1% low FPS: 53,3
FRAPS avg 1% low: 41,6

Definitiv näher am local avg als am normalen 1% low

Die normalen 0,1% low Werte passten hierbei übrigens mit 23,84(FRAPS) und 23,8(MSI) exakt zusammen.
 
Taxxor schrieb:
Bei FRAPS sieht man zwischendrin Schwankungen 13 zu 19ms. OCAT geht an diesen Stellen ebenfalls hoch bzw. runter, bleibt aber insgesamt immer zwischen 16-17ms.
Dann hast du oben die Beschriftung falsch:
Taxxor schrieb:
Rechts: OCAT, Links: FRAPS
Ansonsten hast du eventuell die falsche Spalte aufgetragen...."MsBetweenPresents" sind bei OCAT die Frametimes wie sie aus der Game Engine kommen und das ist es was Fraps ausgibt.
Das ist sozusagen möglichst nah an dem was die CPU berechnet hat und damit meine Wahl für CPU Benchmarks.
"MsUntilDisplayed" sind glaube ich die Abstände zu denen die GPU die Frames rausgibt.....da ist dann Framepacing mit drin, was den Verlauf natürlich glättet und schönt.
Mir hat das nicht gefallen, denn wenn ich Ruckler gespürt habe, dann habe ich die in den Fraps Daten gefunden.
In den Framepacing daten mag die Ausgabe gleichmäßig sein, aber wenn der Inhalt nicht gleichmäßig ist, sieht man es trotzdem obwohl die Daten vermelden es wäre alles OK.
 
Baal Netbeck schrieb:
Dann hast du oben die Beschriftung falsch:
Ups, mein Fehler, links ist natürlich OCAT.

Baal Netbeck schrieb:
Ansonsten hast du eventuell die falsche Spalte aufgetragen...."MsBetweenPresents" sind bei OCAT die Frametimes wie sie aus der Game Engine kommen und das ist es was Fraps ausgibt.
"MsBetweenPresents" ist die linke Zeile.

Habe aber auch gerade noch mal nachgesehen, sowohl "MsBetweenDisplayChange" als auch "MsUntilRenderComplete" zeigen das gleiche Verhalten.
Sie sind +-0,5ms gleich mit "MsBetweenPresents", laufen zwar manchmal antiproportional dazu, aber bewegen sind auch zwischen 16 und 17ms, wenn "MsBetweenPresents" es tun.
 
  • Gefällt mir
Reaktionen: Baal Netbeck
Zurück
Oben