Hallo zusammen,
vor einiger Zeit gab es ja auf Wiimmfi den ersten Custom-Wettbewerb von Sniki, ein weiterer von Sucht steht auch schon bereit und weitere sollen auch noch entwickelt werden. Ein Problem, worauf Sniki und ich beim Erstellen von "Blätterwald rückwärts" dauerhaft gestoßen sind, ist das Dateigrößenlimit von 20.480 Bytes für den Wettbewerb, also ca. 20.400 Byte für die SZS-Datei.
Mit mehreren Tricks (leere KMP-Bereiche per Hex-Editor löschen und nicht leer lassen, Texturen runterskalieren, speziell angepasste Version von wszst [danke @Wiimm] mit geringfügig besserer Kompression genutzt) haben wir es dann endlich geschafft, die Dateigröße unter das Limit zu bekommen.
Wiimm und ich haben in den letzten Tagen am Wettbewerbs-System für Wiimmfi gearbeitet und wollen in Zukunft das Erstellen und Testen von Custom-Wettbewerben vereinfachen - und dabei ist mir der Gedanke gekommen: Eigentlich muss das doch noch besser komprimiert werden können - schließlich sind die Original-Nintendo-Dateien immer noch kleiner als das Ergebnis vom Spezial-wszst.
Es muss also eine bessere Komprimierung geben.
Und die habe ich gesucht und gefunden.
Ich habe mir irgendein Yaz0-Komprimier-tool aus dem Internet geladen (ich hätte auch den Source code von wszst nehmen können, aber das ist schwerer zu bearbeiten als ein stand-alone-tool). Dann habe ich erstmal mit ein paar Dateien getestet, wie sich das unmodifizierte Tool im Vergleich zu den SZS-Tools von Wiimm und den proprietären Tools von Nintendo schlägt: Es war etwas besser als die SZS-Tools (also immerhin schonmal ne Verbesserung), aber immer noch schlechter (größere Dateien) als die Originaldateien von Nintendo. Also habe ich angefangen, mich in die Kompression eingelesen und eine halbe Ewigkeit am Code rumgebastelt. Am Ende kam zwar nur kleinere Änderungen hier und da bei raus (der "generelle" Algorithmus ist ja gleich - lange Blöcke finden, die sich wiederholen), aber die rauszufinden, hat ewig gedauert - immer mehr Versuche mit SZS-Dateien, die entweder defekt (Datei packen -> wieder entpacken -> entspricht nicht bytegenau der Ursprungsdatei) oder deutlich größer waren.
Und was ist das Ergebnis? Die neue Komprimierung dauert zwar ewig (wszst: ca. 5 Sekunden, mein tool: ca. 2-3 Minuten pro Datei), aber die entstehende Datei ist nicht nur kleiner als die von wszst erzeugte, sondern sogar kleiner als die Originaldateien von Nintendo - der neue Algorithmus ist also sogar besser als der von Nintendo. Ich habe zwar keine Ahnung, wie lange die Nintendo-Prozesse bei der Entwicklung des Spiels gebraucht haben, um eine SZS-Datei zu erzeugen, aber da die SZS-Dateien ja nicht so oft neu erzeugt werden müssen, zumindest bei den Wettbewerben, ist der Zeitverlust ja relativ egal - hat ja keiner vor, diese Monster-Kompression für Wiimms MKW Fun mit ~250 Strecken einzusetzen (2 Minuten pro Datei, 250 Strecken mit je zwei Dateien => 1000 Minuten => 16 Stunden).
Ein paar Vergleichswerte:
Common.szs: Originalgröße 1.180.527 B, wszst (Stufe 10): 1.181.289 B (100,06 % der Nintendo-Dateigröße), neues Tool: 1.179.576 (99,91 % der Nintendo-Größe)
Vulkangrollen: Originalgröße 3.402.114 B, wszst (Stufe 10): 3.410.456 B (100,25 % der Nintendo-Dateigröße), neues Tool: 3.387.791 (99,58 % der Nintendo-Größe)
Rainbow Road Originalgröße: 2.244.260 B, wszst (Stufe 10): 2.246.491 B (100,10 % der Nintendo-Dateigröße), neues Tool: 2.242.187 (99,90 % der Nintendo-Größe)
(EDIT: Habe auch mal einen Nintendo-Wettbewerb (6660 B Nintendo, 6660 B wszst (identisch), 6651 B neues Tool (9 Byte gespart)) und einen Custom-Wettbewerb (18420 B wszst, 18323 B neues Tool, 97 Byte gespart)
Eine Ersparnis von höchstens 0,7 Prozent (Vulkangrollen, Vergleich wszst - neues Tool) klingt jetzt nicht so besonders, aber da wir wie gesagt schon am Rand der Dateigröße kratzen ist da jedes einzelne Byte wichtig - und jetzt haben wir bis zu 100-200 Byte zusätzliche Dateigröße (also, einen bis zu soundsoviel Byte übergroßen Wettbewerb kriegt mein Tool noch (je nach Kompressionsfaktor) unter das Limit.
Falls jemand das Tool mal testen möchte, entweder zum Ausprobieren oder um einen eigenen Custom Track noch ein bisschen zu komprimieren, habe es mal für Linux (32/64), Windows (32/64), Raspberry (ARM) kompiliert. Ist ein Kommandozeilentool (wie wszst), braucht als Parameter ne U8-Datei. Wszst kann ne SZS-Datei zu ner U8 konvertieren mit
Irgendwann schreibe ich mal noch ein Script, welches mal alle SZS-Dateien im ganzen Spiel entpackt, mit wszst und meinem Tool neu packt und die Ergebnisse vergleicht. Bisher habe ich keine Datei gefunden, bei der wszst oder Nintendo besser als dieses Tool war.
Fragen zu dem Programm können gerne hier gestellt werden.
Leseratte
EDIT 27.06., 21:20: Raspberry-Version war kaputt, kleines Update.
vor einiger Zeit gab es ja auf Wiimmfi den ersten Custom-Wettbewerb von Sniki, ein weiterer von Sucht steht auch schon bereit und weitere sollen auch noch entwickelt werden. Ein Problem, worauf Sniki und ich beim Erstellen von "Blätterwald rückwärts" dauerhaft gestoßen sind, ist das Dateigrößenlimit von 20.480 Bytes für den Wettbewerb, also ca. 20.400 Byte für die SZS-Datei.
Mit mehreren Tricks (leere KMP-Bereiche per Hex-Editor löschen und nicht leer lassen, Texturen runterskalieren, speziell angepasste Version von wszst [danke @Wiimm] mit geringfügig besserer Kompression genutzt) haben wir es dann endlich geschafft, die Dateigröße unter das Limit zu bekommen.
Wiimm und ich haben in den letzten Tagen am Wettbewerbs-System für Wiimmfi gearbeitet und wollen in Zukunft das Erstellen und Testen von Custom-Wettbewerben vereinfachen - und dabei ist mir der Gedanke gekommen: Eigentlich muss das doch noch besser komprimiert werden können - schließlich sind die Original-Nintendo-Dateien immer noch kleiner als das Ergebnis vom Spezial-wszst.
Es muss also eine bessere Komprimierung geben.
Und die habe ich gesucht und gefunden.
Ich habe mir irgendein Yaz0-Komprimier-tool aus dem Internet geladen (ich hätte auch den Source code von wszst nehmen können, aber das ist schwerer zu bearbeiten als ein stand-alone-tool). Dann habe ich erstmal mit ein paar Dateien getestet, wie sich das unmodifizierte Tool im Vergleich zu den SZS-Tools von Wiimm und den proprietären Tools von Nintendo schlägt: Es war etwas besser als die SZS-Tools (also immerhin schonmal ne Verbesserung), aber immer noch schlechter (größere Dateien) als die Originaldateien von Nintendo. Also habe ich angefangen, mich in die Kompression eingelesen und eine halbe Ewigkeit am Code rumgebastelt. Am Ende kam zwar nur kleinere Änderungen hier und da bei raus (der "generelle" Algorithmus ist ja gleich - lange Blöcke finden, die sich wiederholen), aber die rauszufinden, hat ewig gedauert - immer mehr Versuche mit SZS-Dateien, die entweder defekt (Datei packen -> wieder entpacken -> entspricht nicht bytegenau der Ursprungsdatei) oder deutlich größer waren.
Und was ist das Ergebnis? Die neue Komprimierung dauert zwar ewig (wszst: ca. 5 Sekunden, mein tool: ca. 2-3 Minuten pro Datei), aber die entstehende Datei ist nicht nur kleiner als die von wszst erzeugte, sondern sogar kleiner als die Originaldateien von Nintendo - der neue Algorithmus ist also sogar besser als der von Nintendo. Ich habe zwar keine Ahnung, wie lange die Nintendo-Prozesse bei der Entwicklung des Spiels gebraucht haben, um eine SZS-Datei zu erzeugen, aber da die SZS-Dateien ja nicht so oft neu erzeugt werden müssen, zumindest bei den Wettbewerben, ist der Zeitverlust ja relativ egal - hat ja keiner vor, diese Monster-Kompression für Wiimms MKW Fun mit ~250 Strecken einzusetzen (2 Minuten pro Datei, 250 Strecken mit je zwei Dateien => 1000 Minuten => 16 Stunden).
Ein paar Vergleichswerte:
Common.szs: Originalgröße 1.180.527 B, wszst (Stufe 10): 1.181.289 B (100,06 % der Nintendo-Dateigröße), neues Tool: 1.179.576 (99,91 % der Nintendo-Größe)
Vulkangrollen: Originalgröße 3.402.114 B, wszst (Stufe 10): 3.410.456 B (100,25 % der Nintendo-Dateigröße), neues Tool: 3.387.791 (99,58 % der Nintendo-Größe)
Rainbow Road Originalgröße: 2.244.260 B, wszst (Stufe 10): 2.246.491 B (100,10 % der Nintendo-Dateigröße), neues Tool: 2.242.187 (99,90 % der Nintendo-Größe)
(EDIT: Habe auch mal einen Nintendo-Wettbewerb (6660 B Nintendo, 6660 B wszst (identisch), 6651 B neues Tool (9 Byte gespart)) und einen Custom-Wettbewerb (18420 B wszst, 18323 B neues Tool, 97 Byte gespart)
Eine Ersparnis von höchstens 0,7 Prozent (Vulkangrollen, Vergleich wszst - neues Tool) klingt jetzt nicht so besonders, aber da wir wie gesagt schon am Rand der Dateigröße kratzen ist da jedes einzelne Byte wichtig - und jetzt haben wir bis zu 100-200 Byte zusätzliche Dateigröße (also, einen bis zu soundsoviel Byte übergroßen Wettbewerb kriegt mein Tool noch (je nach Kompressionsfaktor) unter das Limit.
Falls jemand das Tool mal testen möchte, entweder zum Ausprobieren oder um einen eigenen Custom Track noch ein bisschen zu komprimieren, habe es mal für Linux (32/64), Windows (32/64), Raspberry (ARM) kompiliert. Ist ein Kommandozeilentool (wie wszst), braucht als Parameter ne U8-Datei. Wszst kann ne SZS-Datei zu ner U8 konvertieren mit
wszst decompress file.szs. Mein Tool hat nur die Kompressionsroutinen und packt kein U8-Archiv selber zusammen. Windows-Varianten sind ungetestet, Rückmeldung erwünscht.Irgendwann schreibe ich mal noch ein Script, welches mal alle SZS-Dateien im ganzen Spiel entpackt, mit wszst und meinem Tool neu packt und die Ergebnisse vergleicht. Bisher habe ich keine Datei gefunden, bei der wszst oder Nintendo besser als dieses Tool war.
Fragen zu dem Programm können gerne hier gestellt werden.
Leseratte
EDIT 27.06., 21:20: Raspberry-Version war kaputt, kleines Update.
DevkitPro Archiv (alte Versionen / old versions): wii.leseratte10.de/devkitPro/
Want to donate for Wiimmfi and Wii-Homebrew.com? Patreon / PayPal
