Z
ZeroStrat
Gast
Und wie siehts aus? Das Löschen ist hier bei mir sehr stabil.
Z
ZeroStrat
Gast
Lol, weißt du warum AC:O nicht aufgenommen wird?
Eine beispielhaft Datei "C:\\Users\\DevTechProfile\\Documents\\CapFrameX\\Captures\\Delete_Test\\CapFrameX-ACOrigins.exe-2019-08-03T183631.csv".
Der Filter greift, wenn ein Eintrag aus der Ignore-Liste im Namen enthalten ist. Und jetzt schau dir mal unsere Ignore-Liste an.
Ich bin heute unterwegs, also gibt's morgen wieder Updates.
Eine beispielhaft Datei "C:\\Users\\DevTechProfile\\Documents\\CapFrameX\\Captures\\Delete_Test\\CapFrameX-ACOrigins.exe-2019-08-03T183631.csv".
Der Filter greift, wenn ein Eintrag aus der Ignore-Liste im Namen enthalten ist. Und jetzt schau dir mal unsere Ignore-Liste an.
Ergänzung ()
Taxxor schrieb:
Ich bin heute unterwegs, also gibt's morgen wieder Updates.
- Registriert
- Mai 2011
- Beiträge
- 21.160
Ich glaube ich muss gar nicht rein schauen^^ZeroStrat schrieb:Der Filter greift, wenn ein Eintrag aus der Ignore-Liste im Namen enthalten ist. Und jetzt schau dir mal unsere Ignore-Liste an.
Aber den kann man doch bestimmt so einstellen, dass er nur zusammenhängende Wörter filtern soll? Das kann ja auch noch bei anderen Titeln passieren.
Ergänzung ()
@ZeroStrat Oh Oh....
Ich habe gerade mit der Version aus dem Visual Studio heraus drei Aufnahmen von Jedi Fallen Order gemacht mit Festeinstellung 25s
So siehts aus
Es liegt auch nicht an VS, gerade in den Master Branch gewechselt und da sinds glatte 25s.
Red Dead Redemption auch noch mal angeschmissen, da sinds im Comparison Branch 24.76s und im Master 25s.
Und den Noir Bench hab ich auch noch mal nachgeschaut, mit der 1.2.5 und den 3s Differenz warens 89.97s, mit der aus dem VS waren es 89.21s.
Scheinbar funktioniert der Kompensationsansatz nach dem Einbau der QPCTime Parameter nicht mehr, oder hast du den generell rausgenommen weil die QPCTime das komplett regeln sollte?
Zuletzt bearbeitet:
Z
ZeroStrat
Gast
Da stimmt aber was nicht in deinem Code?! Ich habe das so erweitert, dass QPCTime nur für den Startwert des Intervalls genommen wird. Der Rest wird drum herum kompensiert. Lass uns das morgen mal debuggen.Taxxor schrieb:
Z
ZeroStrat
Gast
Hast du mal auf release gestellt und aus dem Ordner heraus gestartet?
- Registriert
- Mai 2011
- Beiträge
- 21.160
Eben auch mal gemacht, gleiches Ergebnis.
10s eingestellt
In deinen Commits stand auch was von "recording length adjustment when capture time is set", dachte da liegts irgendwie dran, aber wenn ich manuell benche und mit mit Stoppuhr 10s abzähle, sinds auch unter 9s.
Hast du das denn bei dir in den letzten 2 Tagen getestet und die Zeiten haben immer gepasst?
10s eingestellt
In deinen Commits stand auch was von "recording length adjustment when capture time is set", dachte da liegts irgendwie dran, aber wenn ich manuell benche und mit mit Stoppuhr 10s abzähle, sinds auch unter 9s.
Hast du das denn bei dir in den letzten 2 Tagen getestet und die Zeiten haben immer gepasst?
Zuletzt bearbeitet:
Z
ZeroStrat
Gast
Ich habe nochmal was angepasst. Insbesondere verrät einem der Logger jetzt mehr. Wenn der Eintrag "Length captured data QPCTime start to end with buffer in sec" unter 20 Sekunden liegt (wenn 20 Sekunden eingestellt sind), dann stehen einfach nicht genügend Daten zur Verfügung. Daher habe ich den Precise Buffer am Ende vergrößert.
- Registriert
- Mai 2011
- Beiträge
- 21.160
@ZeroStrat die ersten beiden waren 9,98 und 9,99, die nächsten beiden waren wieder weniger.
Hier der Log
Kann es einfach sein, dass der Sicherheitsoffset am Ende jetzt noch viel größer gemacht werden muss?
Immerhin waren die Aufnahmen vor dem QPCTime Ansatz ja, auf einem zeitstrahl betrachtet, 1-2s nach rechts versetzt und wir haben den Offset am Ende danach ausgerichtet.
Jetzt, wo dieser Versatz am Anfang verschwunden ist, muss er aber am Ende zum Offset dazukommen, weil die ganze Aufnahme ja 1-2s nach links rückt und so am Ende mehr fehlt als vorher.
Hier der Log
Ergänzung ()
Kann es einfach sein, dass der Sicherheitsoffset am Ende jetzt noch viel größer gemacht werden muss?
Immerhin waren die Aufnahmen vor dem QPCTime Ansatz ja, auf einem zeitstrahl betrachtet, 1-2s nach rechts versetzt und wir haben den Offset am Ende danach ausgerichtet.
Jetzt, wo dieser Versatz am Anfang verschwunden ist, muss er aber am Ende zum Offset dazukommen, weil die ganze Aufnahme ja 1-2s nach links rückt und so am Ende mehr fehlt als vorher.
Zuletzt bearbeitet:
Z
ZeroStrat
Gast
Es sind Schwankungen von über 2 Sekunden möglich, daher setzen wir den Precise Buffer auf 2500ms. Liegt jetzt bei 2000ms. Kannst du ja selbst im Code schnell anpassen.
- Registriert
- Mai 2011
- Beiträge
- 21.160
Wo steckt die Zahl denn im code? Dann teste ich mal ein bisschen durch und sobald ich irgendwo weniger als x.97 sehe erhöhe ich sie entsprechend und geb dir dann durch wie es passt.
Auch habe ich jetzt übrigens wieder den Fall, wenn ich eine Aufnahme nach einer Sekunde wieder beende, dass entweder gar nichts oder eine leere Zeile in der Liste erscheint. Kein realistischer Fall, war aber vorher ja eigentlich auch schon mal gelöst.
Auch habe ich jetzt übrigens wieder den Fall, wenn ich eine Aufnahme nach einer Sekunde wieder beende, dass entweder gar nichts oder eine leere Zeile in der Liste erscheint. Kein realistischer Fall, war aber vorher ja eigentlich auch schon mal gelöst.
Z
ZeroStrat
Gast
Im CaptureViewmodel: Precise_OffsetTaxxor schrieb:
- Registriert
- Mai 2011
- Beiträge
- 21.160
Mit 2500ms passt es bisher in 30 10s Aufnahmen, der Abstand zwischen den beiden Voice Sounds liegt aber bei 12,5s, also so viel mehr wie an Offset eingestellt ist. Habs auch mal verifiziert, indem ich den Offset auf 5000ms gesetzt habe, dann kam der finished Sound nach 15s.
Das ist ziemlich blöd, auch wenn man an einen Countdown im Overlay denkt. Wenn ich 10s einstelle, dann erwarte ich den Stopp Sound ja auch nach 10s und ein Counter würde auch einfach von 10s runterzählen, die Aufname endet aber laut dem Sound und auch nach dem Infotext in CX 2,5s nachdem die 10s runtergelaufen sind, obwohl ich nach diesen 10s schon aufhören kann, zu laufen.
Das ist dann wohl der Punkt an dem die Auswertung beginnt und die Datei geschrieben wird, obwohl die eigentliche Aufnahmezeit schon früher zuende war.
Kann man diesen Punkt irgendwie abpassen um dort den Sound wiederzugeben und den Infotext zu aktualisieren? Müsste ja möglich sein, schließlich muss der eingestellte Offset ja auch einen Starttrigger haben.
Das ist ziemlich blöd, auch wenn man an einen Countdown im Overlay denkt. Wenn ich 10s einstelle, dann erwarte ich den Stopp Sound ja auch nach 10s und ein Counter würde auch einfach von 10s runterzählen, die Aufname endet aber laut dem Sound und auch nach dem Infotext in CX 2,5s nachdem die 10s runtergelaufen sind, obwohl ich nach diesen 10s schon aufhören kann, zu laufen.
Das ist dann wohl der Punkt an dem die Auswertung beginnt und die Datei geschrieben wird, obwohl die eigentliche Aufnahmezeit schon früher zuende war.
Kann man diesen Punkt irgendwie abpassen um dort den Sound wiederzugeben und den Infotext zu aktualisieren? Müsste ja möglich sein, schließlich muss der eingestellte Offset ja auch einen Starttrigger haben.
Zuletzt bearbeitet:
- Registriert
- Mai 2011
- Beiträge
- 21.160
Ne Frage zur Delete Funktion: Kannst du das Löschen von Records zum Verschieben in den Papierkorb machen?
Als ich 2 neu erstellte Testaufnahmen mit DEL löschen wollte, hat sich die Liste nach dem Löschen des ersten Records aktualisiert, der andere Record ist also weiter nach unten gewandert, und ich hab aus Reflex direkt wieder den höchsten Eintrag gewählt und einen Anno 1800 Bench gelöscht, den ich eigentlich nicht löschen wollte.
Wäre nicht passiert, wenn die Liste sich beim Einfügen schon direkt passend andordnet, was ja auch so geplant ist, aber auch dann kann es ja immer mal passieren dass man aus versehen was löscht.
Als ich 2 neu erstellte Testaufnahmen mit DEL löschen wollte, hat sich die Liste nach dem Löschen des ersten Records aktualisiert, der andere Record ist also weiter nach unten gewandert, und ich hab aus Reflex direkt wieder den höchsten Eintrag gewählt und einen Anno 1800 Bench gelöscht, den ich eigentlich nicht löschen wollte.
Wäre nicht passiert, wenn die Liste sich beim Einfügen schon direkt passend andordnet, was ja auch so geplant ist, aber auch dann kann es ja immer mal passieren dass man aus versehen was löscht.
Z
ZeroStrat
Gast
Hab heute schon Code Beispiele dafür rausgesucht. Sollte machbar sein.Taxxor schrieb:
Z
ZeroStrat
Gast
Wir arbeiten an den finalen Issues für die v1.3. Die Capture Funktion wird dank hochauflösender Event-Timer extrem genau. Wir haben die letzten Tage intensiv daran gefeilt.
Die neue Comparison Page wird auch kommen. Wir konnten, denke ich, hohe Standards bei Visualisierung von Benchmark Metriken umsetzen. Das wird richtig gut.
Stay tuned...
Die neue Comparison Page wird auch kommen. Wir konnten, denke ich, hohe Standards bei Visualisierung von Benchmark Metriken umsetzen. Das wird richtig gut.
Stay tuned...
- Registriert
- Mai 2011
- Beiträge
- 21.160
Hier, für interessierte Nutzer, ein paar Tests zur Genauigkeit der Capture Funktion, nachdem wir bis gestern Abend dran gesessen haben:
Erst mal die Aufnahmelänge:
Dadurch, dass unser QPCTime-Ansatz den ersten Frame des Benchmarks jetzt exakt auf den Hotkeyzeitpunkt legt(vorher konnten es 1-2s Versatz gewesen sein, wie im Noir Community Benchmark zu sehen war), mussten wir den zeitlichen Offset am Ende auch noch auf diese zusätzlichen 1-2s anpassen, damit Presentmon auch nach der Aufnahme noch etwas Zeit hat, alle relevanten Daten an CX zu pushen.
Die kleinen Unterschiede bei den manuellen Messungen kommen natürlich durch mich und nicht durch CX, insgesamt war ich aber ziemlich genau^^
Und die .99 Werte bei eingestellter Zeit kommen dadurch zustande, dass bei z.B. 20s Aufnahmezeit zusammen mit der Offset Zeit danach genau so ausgeschnitten wird, dass sie vom Startpunkt aus(über QCPTme) nicht über die 20s gehen. Ein weiterer Frame hätte hier also nach Rundung zu einem 20.01 geführt und wurde deshalb nicht mit reingenommen. Bei der 30s Aufnahme hat es nach Rundung ausnahmsweise gepasst, die genaue Zeit lag bei 29,9994s
Und hier ein weiterer Test zur Genauigkeit der Start- und Endpunkte der Aufnahme:
Hierfür habe ich mich ins Hauptmenü von Witcher 3 begeben, wo ohne Limitierung ca 3500fps anliegen.
Dann habe ich die Capture Time auf 20s gestellt und gleichzeitig mit dem Aufnahme Hotkey eine Stoppuhr gestartet.
Nach genau(so genau wie ich es eben mit meiner Reaktion hinbekommen habe^^) 10s habe ich die FPS mit einem Tool auf 30 begrenzt und nach genau 20s habe ich die Begrenzung wieder entfernt.
Somit habe ich direkt zwei Dinge auf einmal getestet:
1. Der Startpunkt des Benchmarks und somit der erste aufgenommene Frame kommt exakt mit dem Drücken des Hotkeys, daran zu erkennen, dass die Frametimes nach 10,103s(+100ms durch meine Reaktionszeit und die des verwendeten Tools) auf 33ms gestiegen sind.
2. Der Endpunkt des Benchmarks und somit der letzte aufgenommene Frame, ist exakt der Frame bei Beendigung der Aufnahme(ob durch Hotkey oder feste Zeit), daran zu erkennen, dass die letzte Frametime immer noch 33ms beträgt und ich genau bei 20s die Begrenzung entfernt habe.
Eigentlich ist es ja logisch, dass der Endpunkt passen muss, wenn der Startpunkt, wie getestet, exakt passt und wir alles über 20s ab Startpunkt abschneiden, aber es schadet ja nicht, das auch visuell aufzuzeigen^^
Der Bestätigungssound, dass die Aufnahme beendet wurde, kommt jetzt auch immer vor diesem Offset, also genau zu dem Zeitpnkt, wie man es eingestellt hat. Hört man diesen Sound, kann man sich sicher sein, dass danach nichts mehr irgendwie in die Aufnahme mit einfließt.
Und hier zum Vergleich noch mal der gleiche Test mit der aktuellen Release Version(1.2.5) von CX
Hier steigen die Frametimes bei 11,5s obwohl ich die Begrenzung wieder genau 10s nach dem Hotkey aktiviert habe.
Die gesamte Aufnahme ist zwar ebenfalls 20s lang, enthält aber nicht die Zeit vom Hotkey bis 20s danach, sondern die Zeit von 1,5s vor dem Hotkey, bis 18,5s danach.
Ein Update auf Version 1.3.0, die geplant Ende dieses Monats rauskommt, lohnt sich also(nicht nur wegen der nun extremst genauen Capture Funktion)
Erst mal die Aufnahmelänge:
Dadurch, dass unser QPCTime-Ansatz den ersten Frame des Benchmarks jetzt exakt auf den Hotkeyzeitpunkt legt(vorher konnten es 1-2s Versatz gewesen sein, wie im Noir Community Benchmark zu sehen war), mussten wir den zeitlichen Offset am Ende auch noch auf diese zusätzlichen 1-2s anpassen, damit Presentmon auch nach der Aufnahme noch etwas Zeit hat, alle relevanten Daten an CX zu pushen.
Die kleinen Unterschiede bei den manuellen Messungen kommen natürlich durch mich und nicht durch CX, insgesamt war ich aber ziemlich genau^^
Und die .99 Werte bei eingestellter Zeit kommen dadurch zustande, dass bei z.B. 20s Aufnahmezeit zusammen mit der Offset Zeit danach genau so ausgeschnitten wird, dass sie vom Startpunkt aus(über QCPTme) nicht über die 20s gehen. Ein weiterer Frame hätte hier also nach Rundung zu einem 20.01 geführt und wurde deshalb nicht mit reingenommen. Bei der 30s Aufnahme hat es nach Rundung ausnahmsweise gepasst, die genaue Zeit lag bei 29,9994s
Und hier ein weiterer Test zur Genauigkeit der Start- und Endpunkte der Aufnahme:
Hierfür habe ich mich ins Hauptmenü von Witcher 3 begeben, wo ohne Limitierung ca 3500fps anliegen.
Dann habe ich die Capture Time auf 20s gestellt und gleichzeitig mit dem Aufnahme Hotkey eine Stoppuhr gestartet.
Nach genau(so genau wie ich es eben mit meiner Reaktion hinbekommen habe^^) 10s habe ich die FPS mit einem Tool auf 30 begrenzt und nach genau 20s habe ich die Begrenzung wieder entfernt.
Somit habe ich direkt zwei Dinge auf einmal getestet:
1. Der Startpunkt des Benchmarks und somit der erste aufgenommene Frame kommt exakt mit dem Drücken des Hotkeys, daran zu erkennen, dass die Frametimes nach 10,103s(+100ms durch meine Reaktionszeit und die des verwendeten Tools) auf 33ms gestiegen sind.
2. Der Endpunkt des Benchmarks und somit der letzte aufgenommene Frame, ist exakt der Frame bei Beendigung der Aufnahme(ob durch Hotkey oder feste Zeit), daran zu erkennen, dass die letzte Frametime immer noch 33ms beträgt und ich genau bei 20s die Begrenzung entfernt habe.
Eigentlich ist es ja logisch, dass der Endpunkt passen muss, wenn der Startpunkt, wie getestet, exakt passt und wir alles über 20s ab Startpunkt abschneiden, aber es schadet ja nicht, das auch visuell aufzuzeigen^^
Der Bestätigungssound, dass die Aufnahme beendet wurde, kommt jetzt auch immer vor diesem Offset, also genau zu dem Zeitpnkt, wie man es eingestellt hat. Hört man diesen Sound, kann man sich sicher sein, dass danach nichts mehr irgendwie in die Aufnahme mit einfließt.
Und hier zum Vergleich noch mal der gleiche Test mit der aktuellen Release Version(1.2.5) von CX
Hier steigen die Frametimes bei 11,5s obwohl ich die Begrenzung wieder genau 10s nach dem Hotkey aktiviert habe.
Die gesamte Aufnahme ist zwar ebenfalls 20s lang, enthält aber nicht die Zeit vom Hotkey bis 20s danach, sondern die Zeit von 1,5s vor dem Hotkey, bis 18,5s danach.
Ein Update auf Version 1.3.0, die geplant Ende dieses Monats rauskommt, lohnt sich also(nicht nur wegen der nun extremst genauen Capture Funktion
)
Zuletzt bearbeitet:
Ähnliche Themen
