CapFrameX - Capture und Analyse Tool

Der Dark Mode kommt bald, hoffentlich schon nächste Woche als Beta...
1613076762588.png
 
  • Gefällt mir
Reaktionen: cm87 und Nero1
@Wolfgang @Jan

Seit dem letzten Windows Update kann es zu Chrashes (CX, Game, sogar Treiber) kommen, wenn man häufig zwischen Spiel und CX hin und her tabbt. Microsoft hat irgendwas an der DX API geändert. Es scheint zu helfen, wenn man die CX interne GPU Beschleunigung abschaltet. Alle Versuche, das Problem intern in unserem Code so lösen, blieben bisher ohne Erfolg.

1613470763163.png
 
  • Gefällt mir
Reaktionen: Beschi und SVΞN
@ZeroStrat Danke für die Info, werd ich mal im Auge behalten!
Wenn sowas passiert, weiß ich dann woran es liegt.

Bis jetzt hab ich noch keine Probleme gehabt, hab die letzten Tage aber auch nicht mehr gebencht bzw. tabbe eher selten raus.
 
  • Gefällt mir
Reaktionen: ZeroStrat
das OSD erkennt ja automatisch andere Quellen, zbsp MSI Afterburner, und positioniert sich dann darunter.

In meinem falle benutze ich aber nicht MSI Afterburner um das OSD anzuzeigen sondern den Overlay Editor von RTSS. Der wird aber nicht erkannt und CapFrameX OSD wird einfach oben Links angezeigt.
1614512971214.png


Ist vermutlich noch kein bekanntes Problem da die meisten noch nicht den Overlay Editor benutzen um da OSD zu gestallten sondern Hypertext von MSI Afterburner.

Das einfachste sowas zu umgehen wäre X Y Koordinaten für die Startpositionierung des Overlays auszuwählen oder?
 
Für mich sieht das so aus, als überschreibt RTSS damit einfach alles, egal ob noch andere Quellen da sind.


Dann wäre die für mich einfachere Lösung eigentlich, einfach die Sachen im Overlay Editor so weit zu verschieben, dass oben Platz für die anderen Clients ist, anstatt das in jedem zusätzlichen Client einzeln einstellen zu müssen.

Dann muss man zwar die Position ggf immer mal wieder verändern, wenn bei den anderen Clients ne Zeile hinzukommt oder verschwindet, aber das müsste man andersrum bei den Clients auch tun, wenn man im Overlay Editor Zeilen verändert.

Mal schauen, vielleicht bietet die OverlayEditor.dll auch eine Abfrage, wie viele Zeilen das Overlay hat, dann könnten wir uns, sofern die dll aktiv ist, eventuell daran anpassen.

Edit: Er zählt schon mal als eigener Client, das können wir abfragen, jetzt geht's nur darum uns automatisch drunter zu packen, dafür müssten wir and die aktuelle Zeilenanzahl vom Overlay Editor rankommen.

Ich hab auch mal mit der OSD Position rumgespielt, die verschiebt unser OSD um eine feste Pixelzahl, aber relativ zur Zoomstufe, die man im RTSS einstellen kann. Also wenn ich es mit meiner Stufe so eingestellt habe, dass wir genau drunter sind, überlappt es sich wieder etwas, wenn man die Zoomstufe erhöht...
 
Zuletzt bearbeitet:
@Haldi Wir haben jetzt Optionen für die Position der CX Overlay Items eingebaut.

Der OverlayEditor wird zwar als Client erkannt, aber er ist darauf ausgelegt, über mehrere Layer zu arbeiten, daher wird auch nichts nach unten verschoben weil für die interne Logik auch nichts im Weg ist.


Ein automatisches druntersetzen ist leider nicht möglich aufgrund der Natur des OverlayEditors. Du kannst damit ja an beliebigen Stellen auf dem Screen Dinge anzeigen lassen, z.B. einen Block links oben und einen rechts unten.
Da gäbe es keine Möglichkeit, dynamisch eine genaue Position herauszubekommen, wo wir uns hinsetzen sollten.
 
  • Gefällt mir
Reaktionen: Haldi
Das einzige Problem ist, dass das mit dem On-Screen Display fill nicht so toll ist, weil wir damit ja nicht das OSD verschieben sondern nur unsere Infos, der Fill geht dann immer von dem Punkt aus, wo die OSD Position in RTSS eingstellt ist
 
Haldi schrieb:
Joa. Wer gerne Rechts oben oder Links unten wechselt wird damit nicht zufrieden sein^^
Aber normalerweise stellt man das ja einmal ein damit es alles passt und lässt das.
Naja wer komplett wechselt kann es ja über den RTSS machen dann wandert der Fill mit.

Das ist ja nun nur nötig, wenn man den OverlayEditor nutzt, und da könnte man auch den Fill ausschalten und sich, wenn man dann die CX Sachen nicht so gut erkennen kann, mit dem OverlayEditor vmtl einfach an der Stelle nen halbtransparenten Layer drüberpacken, der das gleiche macht
 
Wir haben die Software die letzten Tage "auf uns wirken" lassen und tatsächlich noch einige Dinge gefunden, so dass wir letztlich den Release der v1.6.0 verschoben haben. Das wird wohl auch noch ein paar Tage Dauern. Es handelt sich dabei um nicht kritische Dinge!

@Wolfgang @Jan @Volker

Wie ihr vielleicht mitbekommen habt, haben wir den Rocket Lake Support (Telemetriedaten) testen können. Das sieht soweit gut aus. Ein Vergleich mit HWiNFO beispielsweise gibt die nötige Sicherheit, denke ich mal. Man muss hardwareseitig immer auf der Hut sein, dass das verwendete Mainboard vernünftige Daten an die CPU zurückmeldet. CX greift wiederum direkt über MSR auf die CPU zu. Wir plausibilisieren der Werte letztlich immer über die Delta Methode mit einem externen Energiemessgerät. Netzteileffizienz und Spannungswandlerverluste werden aus den Herstellerangaben entnommen und verrechnet.
 
Zuletzt bearbeitet von einem Moderator:
Release v1.6.0: https://www.capframex.com/download

Changelog
## New features
  • Dark mode
  • Evaluation for multiple records on Sensor page (aggregate and average mode)
  • Selectable "Averaged values" line on Report page
  • Capture start delay timer option
  • Refresh rate monitoring for Nvidia graphics cards (AMD hopefully following in the future)
  • Option on Overlay page to copy overlay item selection to other configs
  • Option on Overlay page to set a custom position for CX overlay (for using it together with RTSS OverlayEditor)
  • Support for Intel 11th gen Rocket Lake CPUs

## Enhancements
  • Capture service performance optimization
  • Values for the capture timers are now decoupled from the general overlay refresh period
  • Changed group control toggle buttons for overlay and sensor items to separate buttons
  • Record comments can now be changed directly in the comment cells of the record list
  • Creating a new sub folder can now also be confirmed by pressing enter
  • Report page column selection
  • 0-30ms y-axis scale option on Analysis tab
  • Custom title now also available on Analysis tab
  • Number of runs for run history changed to 1-20

## Bug fixes
  • "GPU RPM" sensor not refreshing
  • "Used Memory Game" sensor showing 0.00GB in some titles
  • Capture directory expander gets cut off at the bottom when root folder path has two lines
  • Maximized window state gets overwritten to windowed when sending CX to tray
  • Rare capture failure and crash occuring when capture hotkey is registered twice within a few milliseconds(capture hotkey is now blocked for 250ms after each press)

@SV3N Update in der Notiz? Faaaalls du Lust hast... ^^
 
  • Gefällt mir
Reaktionen: tomcat66, Haldi, cm87 und eine weitere Person
Hi,

sorry, falls das schon beantwortet wurde: Aber wie verhindere ich, dass CFX das Capturing bereits nach der ersten von ca. sechs GTA V-Benchmarkszenen selbstständig beendet ("Capture finished")?
 
Indem du die Capture Zeit auf 0 setzt^^
Screenshot 2021-03-31 171628.png
 
  • Gefällt mir
Reaktionen: Shir Khan
Sehr schön, vielen Dank für die superschnelle Antwort. :)

Warum ich gerade capture (capturere?):

Um die FreeSync-Range meines 120 Hz-Monitors FPS-technisch nicht zu überschreiten, setzte ich einen Frame Limiter bei 118 FPS. Ich möchte herausfinden, welche Variante das "glattere" Bild schafft:
  • Limiter per RTSS
  • Limiter per Radeon Treiber
Nehme an, CapFrameX ist das passende Werkzeug dafür.

Screenshot 2021-03-31 173411.png


Im Vergleich ist oben RTSS aktiv, unten Adrenalin. Lässt sich mit dieser Darstellung schon sehen, welche Variante glattere Frametimes produziert? Welche Ansicht sollte ich ggf. stattdessen wählen?

Ach, und noch eine Frage: Kann ich den "Comment" links, mit dem ich den jeweiligen Lauf identifiziere, rechts abbilden? Komme sonst durcheinander, was RTSS und was Radeon ist. Vor allem, wenn ich noch eine Reihe weiterer Spiele teste.
 
Shir Khan schrieb:
Lässt sich mit dieser Darstellung schon sehen, welche Variante glattere Frametimes produziert? Welche Ansicht sollte ich ggf. stattdessen wählen?
Theoretisch ja, wenn der Abstand zwischen avg FPS und P0.2% FPS ähnlich ist, sind es meist auch die Frametimes. In deinem Bild wäre das der zweite Eintrag.
Genauer siehst dus im zweiten Tab auf dieser Seite "Line charts/L-shapes"

Wenn die Frametimes recht ähnlich sind, ist im Graphen mitunter schwer zu erkennen, welche nun wirklich ein kleines bisschen glatter sind, dafür gibts unten die L-Shapes.

Hier ein Beispiel:
Screenshot 2021-03-31 174443.png


Je länger die Linie gerade ist, desto glatter sind die Frametimes.
Orange ist bis zum ca 97. Perzentil gleichauf mit grün, in den letzten 3% der Frames reißt es grün aber weiter hoch, daher wäre hier orange minimal besser.

Bei solche kleinen Unterschieden lohnt es sich übrigens (auch generell immer), mindestens drei Runs pro Setting zu machen, diese per Aggregation zu je einer Datei zusammenzuführen und die dann zu vergleichen, damit man ein belastbareres Ergebnis hat.

Shir Khan schrieb:
Ach, und noch eine Frage: Kann ich den "Comment" links, mit dem ich den jeweiligen Lauf identifiziere, rechts abbilden?
Ja, kannst du.
Unten bei "Contexts" kannst du dir zwei beliebige auswählen, darunter auch den Comment.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Beschi und Shir Khan
Zurück
Oben