CapFrameX - Capture und Analyse Tool

Ist halt schwierig, wenn die Virenscanner dazwischen funken. Du solltest versuchen, CapFrameX als Ausnahme hinzuzufügen. Im Prinzip läuft ja alles automatisch. Du musst einfach nur den selben Speicherort auswählen, in den OCAT schreibt. Eventuell CX mal neustarten.

Welchen Virenscanner verwendest du eigentlich?

Edit: Avast konnte ich schon mal dazu überreden, mein Tool auf die Liste der ungefährlichen Apps zu nehmen... ^^
 
Zuletzt bearbeitet von einem Moderator:
  • Gefällt mir
Reaktionen: cm87
@ZeroStrat
Die Qualität der Screenshots ist bei mir nicht so gut, die fps Werte sind, auch wenn ich einen Screenshot im 1440p Vollbild mache, recht verschwommen. Wenn man den Screenshot dann nicht ebenfalls maximiert betrachtet, sondern etwas kleiner zieht, kann man die Werte kaum noch erkennen.
Bei deinem hochgeladenen Beispiel des PNG Exports sieht es schärfer aus.

Zudem sagt der Tooltip zum verlassen des Screenshot Modes ebenfalls "Switch to Screenshot Mode"




OCAT 1.4 funktioniert bei mir in Metro und in Kindom Come nicht mehr, in Elex schon.
Also das Overlay sehe ich bei allen dreien, der Hook funktioniert also, aber nur in Elex reagiert OCAT auf die Hotkeys zum Aufnehmen oder Ein-/Ausblenden des Overlays.
 
Zuletzt bearbeitet:
@Taxxor Da der Community Benchmark noch nicht gestartet ist, werde ich eine weitere Version nachreichen. Du hast einfach als Tester gefehlt... ;)

Wegen OCAT würde ich mal die Option "Capture performance for all processes" versuchen.
Ergänzung ()

@Taxxor Packe mal diese Dateien ins CapFrameX Verzeichnis und überschreibe einfach die vorhandenen Dateien. Bringt das was?

Hinweis: Das Patch macht nicht wirklich, was es soll. Ich arbeite an einer Lösung...
 

Anhänge

Zuletzt bearbeitet von einem Moderator:
ZeroStrat schrieb:
Wegen OCAT würde ich mal die Option "Capture performance for all processes" versuchen.
Das habe ich auch schon versucht, hat aber nichts gebracht.
Alle drei Spiele liefen auch super mit der 1.3er Version und ich habe eben eine halbe Stunde gebraucht, um herauszufinden, warum meine Tastatur "p" mehr tippen konnte, "P" aber schon, bis ich herausgefunden habe, dass es daran liegt, dass ich"p" als Hotkey bei OCAT festgelegt habe.

Also solange ich OCAT 1.4 offen habe, funktionieren die Tasten, die ich dort als Hotkey gesetzt habem nicht mehr beim normalen schreiben. Mit OCAT 1.3 habe ich das Problem nicht.



ZeroStrat schrieb:
Packe mal diese Dateien ins CapFrameX Verzeichnis und überschreibe einfach die vorhandenen Dateien. Bringt das was?
Nicht wirklich, aber du kannst ja selbst mal schauen, habe mal einen Screenshot im Vollbild gemacht, hier die Datei
https://drive.google.com/file/d/1vE3vzo4Nv3h6gbr9JN_Fz5kCzvTR6lJE/view?usp=sharing
 
Taxxor schrieb:
Alle drei Spiele liefen auch super mit der 1.3er Version und ich habe eben eine halbe Stunde gebraucht, um herauszufinden, warum meine Tastatur "p" mehr tippen konnte, "P" aber schon, bis ich herausgefunden habe, dass es daran liegt, dass ich"p" als Hotkey bei OCAT festgelegt habe.

Also solange ich OCAT 1.4 offen habe, funktionieren die Tasten, die ich dort als Hotkey gesetzt habem nicht mehr beim normalen schreiben. Mit OCAT 1.3 habe ich das Problem nicht.

Lol! Ja, das liegt daran, dass die Eingaben als gehandled gesetzt werden von OCAT. Das sollte so nicht sein...
Ergänzung ()

@Taxxor Der Patch muss aber was bringen. Die Qualität wurde von 96 dpi auf 300 dpi erhöht.
 

Anhänge

  • Mit_Patch.png
    Mit_Patch.png
    414,4 KB · Aufrufe: 424
  • Ohne_Patch.png
    Ohne_Patch.png
    67,7 KB · Aufrufe: 401
Zuletzt bearbeitet von einem Moderator:
ZeroStrat schrieb:
Lol! Ja, das liegt daran, dass die Eingaben als gehandled gesetzt werden von OCAT. Das sollte so nicht sein...
Und vermutlich reagieren die Tasten deshalb auch in den Spielen nicht, nehme ich an? Wobei es dann komisch ist, dass es in Elex funktioniert...

Naja nehme ich eben vorerst wieder die 1.3

ZeroStrat schrieb:
@Taxxor Der Patch muss aber was bringen. Die Qualität wurde von 96 dpi auf 300 dpi erhöht.
Ja, das sagt auch die Auflösung in den Dateieigenschaften(6787x3768), und die Datei ist auch viel größer, aber wenn ich sie dann öffne, sieht es so aus:
766347


Und im Vollbild dann so
766349
 
Zuletzt bearbeitet:
Moin moin,

Sorry für die späte Rückmeldung. Ich nutze Avast Free Anitivirus.
Mittlerweile ist es mir gelungen die Dateien zu sehen. Ich Depp hätte gestern schon die Ignore-List sehen müssen :rolleyes:

Deine letzten Qualitätspatches habe ich noch nicht installiert. Darum ist es wohl auch nicht verwunderlich dass es bei mir wie auf Taxxor's Bildern aussieht. Etwas mehr Schriftgröße könnte nicht schaden, vor allem im Tortendiagramm.

Gruß Beschi
 
Das Quality-Patch könnt ihr links liegen lassen. Ich muss Resampling Filter einsetzen, damit das schärfer wird. Die Schriftgröße passe ich auch noch an.
 
@ZeroStrat Ich habe gerade mal eine Vergleichsmessung zwischen FRAPS und OCAT in Witcher 3 gemacht und bin vielleicht auf einen Fehler bei deinem Programm gestoßen.

Also ich habe eine 30 Sekunden Szene gebencht mit OCAT und FRAPS gleichzeitig.
Dann habe ich mir mit dem Tool von @Baal Netbeck die Werte von FRAPS auswerten lassen und sie mit den Werten in CapframeX verglichen.
766481

766482




Hier mal die wichtigsten Werte, mit Highlight auf den problematischen Wert.
WertFRAPS ToolCapframeX
avg43.9744.01
5%39.7339.76
1%35.7235.84
1% low20.6526.98
0.1%9.228.88
0.1% low8.78.24

Ich dachte zuerst an einen Aufnahmefehler bei OCAT, aber sowohl die besseren als auch die schlechteren Werte passen ja zusammen, die 0.1% Werte sind bei CapframeX sogar schlechter, trotzdem ist der 1% low fast 6,5fps besser.



Dann habe ich mir mal die OCAT Datei genommen, die "MsBetweenPresents" absteigend sortiert, die schlechtesten 14 Stück (1%low) gemittelt und in FPS umgerechnet.
Ergebnis: 20,66 und damit ziemlich exakt das Ergebnis vom Fraps Tool.
Wenn ich das gleiche für die schlechtesten zwei (0.1% low) mache komme ich auch auf genau die 8,7fps des Fraps Tools.
Die Rohdaten von Fraps und OCAT sind also identisch.

766492


Oder nutzt du eine andere Methode für deine Berechnung?
Selbst wenn ich das 0.1% Quantil nehme, in diesem Fall ist es der zweitschlechteste Wert(108.503ms), dann sind das ebenso genau 9.22fps, wie beim Fraps Tool.
Hier kann ich mir vorstellen, dass du für das Quantil nicht genau einen Wert nimmst sondern den Schnitt aus zwei Werten, denn 0.1% von 1318 Werten ist mit 1.32 ja kein gerader Wert, BaalNetbeck nimmt hier dann den nächst höheren Wert, also den 2. und kommt damit auf 9.22fps.

Deine 35,84fps für 1% würden zum Mittelwert von Wert 13 und Wert 14 passen, deine 8.88fps für den 0.1% passen aber nicht zum Mittelwert von Wert 1 und Wert 2, hier bekäme man logischerweise den gleichen Wert wie die 0.1% low, nämlich 8.70fps.


Die Variante vom Fraps Tool(die genau das macht, was ich hier manuell gemacht habe) bringt ja auch mit den OCAT Daten die exakt gleichen Ergebnisse wie mit den FRAPS Daten, deine Werte weichen alle minimal davon ab, aber dein 1% low Wert mit 26.98 und damit einer Abweichung von über 6fps sticht dann schon sehr raus.
Selbst wenn ich den Schnitt der schlechtesten 28 Frames (2% low) nehme, käme ich auf 26.56fps und damit immer noch minimal schlechter als dein 1% low Wert.




Ach ja, und noch mal zu dem hier
ZeroStrat schrieb:
Lol! Ja, das liegt daran, dass die Eingaben als gehandled gesetzt werden von OCAT. Das sollte so nicht sein...
Auf Nachfrage bei Github bekam ich als Antwort, dass das sehr wohl so sein soll.
yes, that's actually the expected behavior, because it's now using the global windows hotkey approach - which owns the key exclusively. We did the change because on some apps the old hotkey approach wasn't working. Why this method isn't working now on some other games, I need to investigate.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Baal Netbeck und ZeroStrat
@Taxxor Du testest nicht nur, du drehst die Software auf links. :D

Erstmal die PNG Exports und Layouts. Anbei der neue Stand mit 30% mehr Sharpness und größerer Schrift.

Das Quality-Patch V2 kommt gleich...
 

Anhänge

  • MetroExodus_2019-23-3_10-42-04_CX_Analysis.png
    MetroExodus_2019-23-3_10-42-04_CX_Analysis.png
    123,9 KB · Aufrufe: 392
ZeroStrat schrieb:
@Taxxor Du testest nicht nur, du drehst die Sofware auf links. :D
Andere Leute werden für sowas bezahlt^^

Ich kann dir auch die OCAT Datei dieses Benches geben, wenn du da selbst reinschauen möchtest.
 
Ja, gib mir bitte die OCAT Datei.
Ergänzung ()

Quality Patch Nr. 2. Einfach die Dateien in den Ordner kopieren.
 

Anhänge

  • Gefällt mir
Reaktionen: cm87
ZeroStrat schrieb:
Ja, gib mir bitte die OCAT Datei.

Der Unterschied im avg Wert kommt übrigens nur daher, dass die FRAPS Messung einen Frame weniger enthält, berechne ich den Schnitt aus allen Werten der OCAT Datei, komme ich auf genau 44,008 und damit auf das, was auch Capframe X sagt.

Und diese Gegenüberstellung ist vielleicht auch interessant wegen den Quantilen, wo kommen die 113ms her?
766533

Das ist weder ein Wert, der in der Liste existiert, noch ein Wert, den ich irgendwie aus einem Mittelwert bekommen könnte(121,374 und 108,503 ergeben 114,9).
99.5%, 99.8% und 99.95% passen hingegen perfekt(wenn du immer aufrundest, denn 30,246ms wären eigentlich 30.2 und nicht 30.3)


Gerade nochmal gesucht, bei den MsBetweenDisplayChange findet sich als zweitschlechtester Wert eine 112,468, was zumindest nahe an 113 liegt(auch wenn dann hier eher eine 112.5 stehen müsste).
Hingegen passen hier dann die 99.95% und 99.8% Werte mit 129.4ms und 108.8ms nicht.


Achja und die Prozentwerte bei den L-Shapes haben noch Kommata als Dezimaltrenner ;)
 

Anhänge

Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: cm87
Taxxor schrieb:
Das ist weder ein Wert, der in der Liste existiert, noch ein Wert, den ich irgendwie aus einem Mittelwert bekommen könnte(121,374 und 108,503 ergeben 114,9).
99.5%, 99.8% und 99.95% passen hingegen perfekt(wenn du immer aufrundest, denn 30,246ms wären eigentlich 30.2 und nicht 30.3)

Es ist das gewichtete Mittel, also letztlich eine lineare Interpolation, wenn der Wert (eigentlich der Index zum p-Quantil) so in der Liste nicht existiert.

Taxxor schrieb:
Achja und die Prozentwerte bei den L-Shapes haben noch Kommata als Dezimaltrenner ;)

Gut gesehen Sherlock. Korrigiere ich noch.
 
ZeroStrat schrieb:
Es ist das gewichtete Mittel, also letztlich eine lineare Interpolation, wenn der Wert (eigentlich der Index zum p-Quantil) so in der Liste nicht existiert.
Okay, also dann ist z.B. der 107.2ms Wert für das 99.8% Quantil(theoretisch der 2,6. Wert) nur zufällig so gleich mit den 107,187ms des dritten Wertes, weil das gewichtete Mittel vom zweiten und dritten Wert (108,503 und 107,187) auf eine Nachkommastelle gerundet immer noch 107,2 ist?
 
Ich habe die von mir verwendete Bibliothek (MathNet.Numerics) jetzt einmal genauer analysiert. Es wird sogar scheinbar eine kubische Interpolation für die Berechnung von nicht ganzzahligen Indizes verwendet. Hut ab. So wird es noch realistischer.
 
Was erklärt, weshalb deine Quantile im unteren Bereich etwas schlechter sind als, wenn man einfach jeden Wert auf den nächsten ganzen Frame aufrundet.

Was es aber nicht erklärt, sind die Low Werte.
Der min Wert meines Benches ist bei dir gleich mit dem 0.1% Low Wert, was ja eigentlich nicht sein kann, da der 0.1% Low Wert zwischen Min und dem P0.1 liegen müsste.
 
Die Berechnung der Low Average Werte habe ich so umgestellt, dass konsistent nur mit Frametimes gerechnet wird und erst zum Schluss eine Transformation in FPS stattfindet. Die Werte passen jetzt auch zu den FRAPS Werten.

Im Übrigen mache ich das bei den Standard Average Werten auch so. Dann ist es nun alles in allem konsistent.
Ergänzung ()

Eine neue Version muss dann so oder so her. Habt ihr noch Vorschläge für Features? Aber bitte nichts großes... ^^
 
Aber mal als jemand, der nicht so tief in den mathematischen Funktionen drin steckt:

Wenn mein 0.1% Wert genau berechnet den 1,319. schlechtesten Frame bedeuten würde, dann würde ich mir eigentlich nur den 1. schlechtesten und den 2. schlechtesten Frame ansehen.

In diesem Fall wären das 121,374ms und 108,503ms.
Jetzt könnte man den Mittelwert nehmen, was nicht so genau wäre.
Ich würde jetzt, da der genaue Frame 1,319 sein soll, das in die Berechnung miteinbeziehen, sodass der 1. schlechteste mehr Gewicht hat, da die Zahl näher an 1 als an 2 ist.

Also (121,374*0,681+108,503*0,319)=117,26

Das wäre doch im Prinzip die genauste Angabe des 1,319. Frames und damit des 0.1% Quantil oder nicht?

Aber ist diese Angabe nicht auch sowieso standardisiert, also gibt es nicht eigentlich nur eine einzige richtige Art, sie zu berechnen?
Befrage ich Wikipedia nach Quantilen, so steht dort, dass bei Quantilen immer auf die nächste kleinere ganze Zahl abgerundet wird, in unserem Fall also 1(1,319) für den 0.1% Wert bzw 13(13,19) für den 1% Wert.

ZeroStrat schrieb:
Die Berechnung der Low Average Werte habe ich so umgestellt, dass konsistent nur mit Frametimes gerechnet wird und erst zum Schluss eine Transformation in FPS stattfindet. Die Werte passen jetzt auch zu den FRAPS Werten.
Wie genau kam denn jetzt die Berechnung vorher auf 26,98fps statt 20,65fps?

ZeroStrat schrieb:
Habt ihr noch Vorschläge für Features? Aber bitte nichts großes... ^^
Wie schaut's mit dem An- bzw. Abwählen der übrigen Parameter aus? Also jeden Wert per Haken reinnehmen oder rausnehmen können so, dass es nicht nach einem Neustart wieder zurückgesetzt wird

Ist das was großes?
 
Zuletzt bearbeitet:
Ich bin auch zunächst von einem gewichteten Mittel ausgegangen. Es gibt sehr unterschiedliche Strategien, um mit den nicht ganzzahligen Indizes umzugehen (Runden, Ceil, Floor, Interpolation). Aber keiner dieser Ansätze ist jetzt der richtige. Dass jetzt hier in der von mir verwendeten Lib Strategien verwendet werden, die über lineare Interpolation hinausgeht, begrüße ich sehr. Das ist gerade dann hilfreich, wenn die Anzahl der Samples eher gering ist und wenn es an der Rändern große Sprünge gibt. Je weniger Ausreißer es gibt, desto näher rücken die Ansätze vom Ergebnis her zusammen.

Wegen der zusätzlichen Features: ich hätte Lust auf die Approximation des Inputlags. ^^ Das baue ich auf jeden Fall noch ein.

Und dass OCAT die p-Taste auf handled setzt und dadurch "blockiert", naja, das mag so geplant sein, aber strange finde ich das schon.

Taxxor schrieb:
Wie genau kam denn jetzt die Berechnung vorher auf 26,98fps statt 20,65fps?

Ich habe das p-Quantil der FPS berechnet und den Wert als Schranke genommen für eine Teilsequenz, dessen Average ich berechnet habe. Das führt aber zu sog. geschätzen Mittelwerten, die man beispielsweise verwenden muss wenn man nur FPS Werte hat oder ein Downsampling oder ein zyklisches Sampling zuvor durchgeführt wurde.
Nun berechne ich das (1-p)-Quantil der Frametimes und verwende diesen Werte ebenfalls als Schranke für eine Teilsequenz, dessen Average ich berechne. Anschließend berechne ich 1000/(Average der Teilsequenz).
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben