Kann mir jemand kurz erklären wozu Clonk die zahlreichen eigenen Archivformate (c4f, c4d, c4g) hat? Sind das reine Archive oder kommt da noch eine Kompression hinzu? Wenn ja, was für ein Algorithmus wird verwendet und mit welchen gängigen Formaten (*.zip, *.7zip, *.tar.gz, *.tar.xz …) kann ich die vergleichen? Was ist der Grund dafür, Clonk Spieldateien als Archiv zu verpacken? Wundert mich schon lange :)
Besten Dank!
Das sind einfach Zipdateien, aber mit etwas geändertem Header. Irgendwo gab’s mal ne Anleitung zu dem Format, aber die habe ich jetzt nicht gefunden.
Bei Clonk ist das Program „c4group“ dabei, was die Dateien packen und entpacken kann. Der Quellcode für OpenClonk’s c4group ist hier, falls es hilft.
Der Grund die zu archivieren ist vor allem, dass die so leichter zu handhaben sind (zB wenn man eine Datei vom CCAN runterläd) und dass die Ladegeschwindigkeit damit sogar höher ist, weil einfach eine Datei sequentiell gelesen werden kann und weniger auf der Festplatte hin- und hergesprungen wird. Wie sehr das bei SSDs jetzt noch ne Rolle spielt, weiß ich nicht.
Danke Zapper.
Soweit ich weiss spielt es bei SSDs so gut wie keine Rolle mehr, da dort andere Aspekte wichtiger sind z.B. Wear Leveling bzw, dass man Speicherbereiche nicht einfach ohne Grund herumkopiert weil das die Lebensdauer verringert.
Die Frage ist eher ob man heute Clonk lieber mit einem neumodischen Kompressionsalgorithmus ausstatten würde wie *tar.xz (soweit ich weiss im Moment State of the Art). Damit müsste man die Datei allerdings vor dem Spiel zuerst entpacken, weil die Dateien anders als beim Zip format Archivübegreifend komprimiert sind.
Wie sieht es denn z.B. bei Legacy Clonk / Clonk Rage aus? Werden die Dateien dort vor dem Start eines Szens immer zuerst entpackt?
Das Dateiformat wird hier beschrieben: C4Group Dateispezifikation
Im OpenClonk-Forum gab es schon einige Ideen für ein neues Format:
Nur kurz zur Klarstellung:
Selbst wenn ein anderes Format magischerweise doppelt so schnell beim Laden wie C4Group wäre, würde es den Spielstart nicht um viel beschleunigen. Hier mal ein paar Profilerscreenshots vom Laden von CMC - Black Thunder:
zng_inflate_fast ist definitiv dabei, dass 7% des Ladens aus Gruppen mit dem Dekomprimieren der Gruppen verbracht werden, überrascht mich jetzt aber nicht. Ins Auge stechen tun viel mehr C4AulFuncMap::GetFunc, was beim Scriptlinken aufgerufen wird (der Teil, der mit dem Loggen von C4AulScriptEngineLinked, n warnings, n errors beendet wird), und CDecoderFrame::CopyPixels, was beim Laden von Grafiken eine Rolle spielt. (Mit libjpeg unter macOS/Linux sind es äquivalente Zahlen.)
Beim Aufrufbaum zeigt sich das Ganze noch deutlicher. (Angemerkt sei, dass C4DefList::Load rekursiv aufgerufen wird und damit öfters mit verschiedenen Aufrufzeiten aufscheint). Der Großteil entfällt auf Mix_LoadWAV_RW, aka dem Laden von Sounds, sowie dem Laden von Grafiken.
C4AulFuncMap::GetFunc auf.
@Jan @Der_Tod Danke für die Klarstellung. Der Vorteil des *.xz-Formats liegt in seiner geringen Dateigrösse, Komprimierung und Dekomprimierung dauern da natürlich etwas länger. Ausserdem ist es afaik wie bei *tar.gz Format nicht möglich direkt auf Dateien zuzugreifen da das ganze Archiv komprimiert wird und nicht wie im Vergleich zu *.zip nur die einzelnen Dateien. Ich finde die Diskussion interessant. Welches Format würdet ihr aus welchem Grund bevorzugen?
@Fulgen Interessante Aufstellung. Die Dekompressionsalgorithmen sind ja mittlerweile alle auf Multicore und Vektorisierung ausgelegt, da hätte es mich erstaunt wenn signifikant mehr darauf abgefallen wäre :)
Ich lehne mich einfach mal weit aus dem Fenster und behaupte, dass die Kompressionsgüte des Packalgorithmus quasi keine Rolle spielt. Die großen Dateien sind Bilddateien und Sounddateien. Diese sind mit ihren jeweiligen spezifischen Algorithmen schon sehr, sehr gut komprimiert und normalerweise kann da eine generische Komprimierung danach auch nichts mehr rausholen.
Das heißt: Am Ende geht es um die paar kB Textdateien, die in so einem Archiv rumfliegen und ob die jetzt noch 7% besser komprimiert werden, ist egal. Wichtig ist Lesegeschwindigkeit (und evtl. random access Zugriff auf Dateien - weiß ich ehrlich gesagt grad nicht, ob das benutzt wird.).
@Zapper Ich gebe dir im grossen und ganzen recht. So weit ich es verstanden habe wäre bei der archivübergreifenden kompression der vorteil dass ich muster aus verschiedenen bereits komprimierten bilddateien kombinieren kann. Bin da allerdings auch nicht so informiert. Aber unter gegebenen gesichtspunkten würde ich auch unterschreiben dass es keine rolle spielt. Spricht etwas dagegen, das c4* format zu ditchen und einfach *.zip Dateien zu nehmen?
Tja, also an sich spricht nichts dagegen, außer der notwendige Aufwand. Siehe die verlinkten OC Forum Diskussionen, wo mit dem Gedanken gespielt wurde das mit PhysicsFS zu ersetzen (und dann kann man zip und alles andere gratis dazu).
Aber das macht natürlich die Abwärtskompatibilität kaputt. Oder man pflegt beides parallel. Ist jedenfalls nicht mal so an einem Vormittag gemacht.
Warum nicht die Kompression ganz ausschalten und die gepackte Datei als virtuelles Dateisystem mit random access nutzen? So kann das Format bleiben und wir haben eine Abwärtskompatibilität
Das finde in eine gute Idee. Mit etwas Glück scannt ein eventuell auf dem Rechner vorhandener Antivirus nicht jedes Dateifuzzel. Das war früher zumindest ein Performance-Verlust, wenn ein Spiel viele Ressourcen als Einzeldateien hatte.