Dxtory: Frage zur Version & Probleme mit Minecraft

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Dxtory: Frage zur Version & Probleme mit Minecraft

    Anzeige
    Hi,

    ich wollte nur kurz fragen, ob ich die Version 2.0.126 problemlos nutzen kann oder lieber bei 2.0.125 oder 2.0.123 bleiben sollte.

    Außerdem wollte ich fragen, ob es irgendeine Möglichkeit gibt, Minecraft in 3840x2160 Pixeln komprimiert aufzunehmen. Sobald ich die Komprimierung in den Einstellungen des Dxtory Codecs anschalte, habe ich in Minecraft nur 12 FPS oder so (also das Spiel selbst hat nur so wenig FPS, die Aufnahme müsste theoretisch mit 30 FPS laufen, wenn Minecraft mehr FPS hätte). Andere Spiele kann ich komprimiert mit 30 FPS aufnehmen. Wenn ich die Komprimierung ausschalte, wird die Datei riesig, aber Minecraft läuft mit deutlich über 30 FPS. Allerdings muss ich noch auf eine Festplatte warten, um ein RAID 10 aufzubauen, das theoretisch schnell genug für unkomprimierte Aufnahmen sein sollte. Meine Idee mit einem RAID 5 hat leider nicht funktioniert, das schafft nur ca. 50 MB/s schreibend...

    Grüße,
    Magogan

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von Magogan ()

  • Magogan schrieb:

    Sobald ich die Komprimierung in den Einstellungen des Dxtory Codecs anschalte, habe ich in Minecraft nur 12 FPS oder so (also das Spiel selbst hat nur so wenig FPS, die Aufnahme müsste theoretisch mit 30 FPS laufen, wenn Minecraft mehr FPS hätte).

    "Wait for available Buffer" mal abhaken? Sorgt hier zumindest für keinen FPS-Gewinn und bremst bei manchen Spielen die FPS wenn Dxtory nicht hinterher kommt.

    Um die HDD auszuschließen (sprich evtl. ist der Flaschenhals woanders, CPU, RAM oder einfach nur nicht genug PCIe-Bandbreite) einfach mal von "File"- auf "DirectShow"-Output umstellen, gibts dann mehr FPS liegts an der Platte (da der Modus ja eigentlich fürs Streamen gedacht ist und nichts auf Platte schreibt)


    Magogan schrieb:

    Meine Idee mit einem RAID 5 hat leider nicht funktioniert, das schafft nur ca. 50 MB/s schreibend

    Raid5 ist ja nicht schneller nur weil da mehrere Platten im Verbund arbeiten, er schreibt zwar abwechselnd auf die Platten, muss aber immer die Parität berechnen und auf der entsprechenden Platte ablegen, man gewinnt da (abgesehen von Datensicherheit) ja nichts sondern packt eher noch was drauf...

    PS: Sogar meine externe USB3 Platte schafft 120MB/s, RAID5 ist also nicht empfehlenswert...
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • Ja, ich habe ja extra einen RAID-Controller gekauft, der das mit den Paritäten berechnen soll. Aber irgendwie klappt das nicht so ganz bzw. deutlich langsamer als erwartet :D Deswegen habe ich ja inzwischen ein RAID 10 eingerichtet.

    "Wait for available buffer" habe ich bereits deaktiviert. Das RAID ist schnell genug für Aufnahmen in 3840x2160 mit 30 Hz. Und das funktioniert auch in anderen Spielen. Nur Minecraft macht mal wieder Probleme.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Magogan ()

  • 3840x2160er Frames ist ja nicht nur eine HDD Belastung, sondern auch eine enorme CPU belastung. Die CPU muss die ja auch codieren. Mit Kompression ist der Aufwand natürlich signifikant höher. Dazu noch das CPU intensive Minecraft. Kein Wunder das du hier Probleme kriegst.

    Nimm halt in 25fps auf. Das entlastet schonmal und sieht auf yt eh besser aus.

    Wait For Buffer kann aus bleiben. Lediglich SyncLock sollte an sein. Das gilt an alle. Wait For Buffer zieht bei manchen Spielen tatsächlich paar fps und SyncLock alleine ist eig. auch ausreichend. In Zukunft werde ich also nur noch SyncLock aktiviert empfehlen ^^
    Aktuelle Projekte/Videos


  • Anzeige
    Ich habe den Sinn von "Wait for available buffer" eh nie verstanden. Ob ich nun in der Aufnahme nur 25 statt 30 FPS habe oder in der Aufnahme und im Spiel nur 25 statt 30 FPS habe. Das hilft bei der Fehlersuche, mehr aber auch nicht...

    In 25 FPS aufzunehmen wird auch nichts bringen, da Minecraft ja nicht mal die 25 FPS schafft. Und ich habe bei der Aufnahme alles überprüft. Sowohl CPU als auch Festplatte sind nicht ansatzweise zu 100% ausgelastet gewesen, die CPU war sogar nur bei 25% oder so. Trotzdem hatte ich in Minecraft nicht einmal 30 FPS. Und das Komprimieren der Frames sollte auch kein Problem sein, das klappt sogar in AC4 problemlos, das kann ich nämlich komprimiert aufnehmen (ebenso wie WoW und HDRO, andere habe ich noch nicht getestet).

    Welche Version von Dxtory soll ich denn nun nehmen? 2.0.123 hatte letztens noch einwandfrei funktioniert und 2.0.125 habe ich aktuell installiert.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Magogan ()

  • Minecraft ist ne B'''ch was das Aufnehmen angeht... ohne Aufnahme hab ich (mit Shader) ne FPS (je nach Komplexität der Umgebung) von 30-60 (ab 60 regelt der VSync das runter, weil der Monitor eh nicht mehr macht), nehme ich auf sackt das ganze auf 20-30fps runter... und weder CPU (idlet zu 50% rum) noch Grafikkarte (idlet auch zu 25% rum) haben damit irgendwas zutun... zumindest dem Anschein nach...

    Und selbst wenn ich per DirectShow ohne Plattenbelastung teste so ist die FPS gleich niedrig... Lagarith ist dabei "schlechter" als der Dxtory-Codec, Komprimierung scheint auch kaum Unterschiede zu machen (2-3 FPS vllt.)...

    Habs aber noch nicht probiert Dxtory und Minecraft auf unterschiedliche Kerne zu legen, evtl. würde ja das was ändern... Lagarith auf Single-Core umzustellen hat zumindest im Test keinen (FPS blieb gleich) Unterschied gemacht, bei anderen Spielen läuft Lagarith im Single-Core-Modus komischerweise besser als Multicore...
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von TbMzockt ()

  • Magogan schrieb:

    Ich habe den Sinn von "Wait for available buffer" eh nie verstanden.

    Das hab ich aber mal beschrieben. Sinn hat es schon. Aber Synchronous Surface Lock ist Absicherung genug.

    In 25 FPS aufzunehmen wird auch nichts bringen, da Minecraft ja nicht mal die 25 FPS schafft.


    Der PC wird doch deutlich weniger belastet wenn du 25 statt 30fps aufnimmst. bedenke das die CPU solche riesigen Frames codieren muss. Da können 25 schon ne hilfe sein.

    Sowohl CPU als auch Festplatte sind nicht ansatzweise zu 100% ausgelastet gewesen, die CPU war sogar nur bei 25% oder so


    boah ich kann das nimmer lesen x.x

    Eine CPU ist nicht erst zu schwach/überfordert wenn da 100% steht <.<

    ne FPS (je nach Komplexität der Umgebung) von 30-60 (ab 60 regelt der VSync das runter, weil der Monitor eh nicht mehr macht)

    ist doch egal. Das Spiel wird trotzdem weicher wenn du mehr fps als 60 hast. Außerdem bremst vsync nur noch mehr rum..

    DirectShow Output ist Unsinn, der setzt nämlich FPS Synchron zur Ausgabe FPS. Also überhaupt keinerlei sinnvoller Test.
    Aktuelle Projekte/Videos


    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von De-M-oN ()