<verklickt, falscher Thread>
Hallo Besucher, der Thread wurde 5,6k mal aufgerufen und enthält 72 Antworten
letzter Beitrag von ogd am
Packer gesucht für Bereich $0350-$ffff
- TheRealWanderer
- Erledigt
-
-
NSU Cruncher von Action 0037-ffff
ok plush war 33-ffff und gewinnt oder ?
Wenn Dir die 4 Bytes wichtig sind, so solltest Du Deinen Code optimieren
Semi-OT und ganz verrückte Idee (kein RLE, sondern Huffman oder LZW oder Derivat):
Man könnte die Low-Nibbles vom Color-RAM als Lookup-Table beim depacken nutzen.
Dann wäre der Depack-Code zwar ein wenig länger um die Nibbles wieder "zusammenzuführen" und um ein wenig mit $01 zwecks IO on/off zu hantieren, aber hätte effektiv einen 2k Lookup-Table...
-
coole Idee. Aber mein depacker muss dann immer $01 umschalten um Lookup zu machen, $01 umschalten um das Byte unter den I/o zu schieben (wenn ich bis ffff depacken muss)
LZW ist mir zu heftig btw.
-
Korrektur: Natürlich nicht 2k Lookup-Table, sondern 2Kibibit, also 512 bytes.
-
schon klar.... nibbles eben (4bit sind keine 8bit)
aber macht das der Exomizer nicht eh schon so ?Habe die Sourcen meines RLE depak eh dazugegeben.
Aber das auf 33 bytes (-2 wegen Port $00/01) also 31 bytes zu reduzieren .... weiss nicht ob das dafür steht.
- init teil (zeile 255-273) muss da weg uns ins hauptprogram nach dem MoveBlock (steht ab $0100)
- Zeile 275 - 382 ist der reine Depak der im Stack bei $0100 steht sollte -> den auf 33 bytes kürzen ist eine Challenge (geht natürlich - einfach wirds nicht)
Die Spiele die ich packte gingen alle Stressfrei (ausser Sonic natürlich) - werde schaun ob Sonic sich mit obigen Packer korrekt crunchen lässt...
-
Wofür soll diese Lookup-Tabelle gut sein? Also welches Problem löst sie, bzw. was wird dadurch besser?
-
"Lookup-Table" ist in dem Kontext nicht die korrekte Bezeichnung: Die bekloppte Idee ist, eine _dictionary-based_ Kompression zu benutzen, welche für das dictionary die low-nibbles des Farb-RAMS benutzt und daher eine max. Länge von 512 bytes haben kann.
Das hätte den Vorteil, dass das dictionary nicht den regulären Speicher belegt - Allerdings verbunden mit dem Nachteil, dass die Entpack-Routine zwangsläufig aufgrund zusätzlicher notwendiger Logik ein wenig länger wird, damit die low-nibbles als dictionary ausgewertet werden können. (Und auch mit langsamer Entpack-Geschwindigkeit verbunden ist.)
Wenn diese Logik länger wird, als 512 bytes, dann gibt es keinen Vorteil, vielleicht ergibt sich auch überhaupt kein Vorteil - ist halt eine bekloppte Idee
-
So ein Wörterbuch ist aber eigentlich auch nur sinnvoll, wenn man damit mehrere Dateien entpacken kann (z.B. Leveldaten von nicht-sequenziellen Leveln).
Mit nur einer Datei gibt es da so gut wie keinen Vorteil gegenüber den üblichen Rückreferenzen.
-
sehe ich auch so. Mein RLE hat für Spiele komplett ausgereicht von Geschw. und Speicherverbrauch und zweiteres kann ein Exomzer dann auch noch 50% verkleinern wenn das sein muss...
Mir war es wichtig $0200-ffff sauber zu können.
Aber eine gute Idee hat es schon:
Jetzt weiss ich das ich den Stack und Zeropage 02-255 im Farbram verstecken kann und meinen depak sagen könnte stelle am Ende diese Daten wieder her mittels Schleife bei $03-$13 und sprung ins Spiel.... ned übel !
-
Bei <$33 Bytes für den Entpacker sehe ich jetzt auch ziemlich sportlich, was anderes als RLE zu bauen.
Dazu sollte er ja nur ein erster Pass sein, damit die Daten klein genug für einen richtigen Packer werden.
Aber mal angenommen, der RLE findet einfach nicht genug, um die Daten passend für den richtigen Packer zu machen... Wären dann Referenzen oder 4Bit-Wörterbuch für einen kleinen Entpacker besser?
-
müsste man statistisch ausrechnen falls hier Hochschul theoretiker im Forum sind. Denke aber dieses Forum ist zu praxislastig
oder ausprobieren mit einigen Spielen welche sich mit den herkömmlichen crunchern kaum verkleinern lassen...
-
müsste man statistisch ausrechnen falls hier Hochschul theoretiker im Forum sind. Denke aber dieses Forum ist zu praxislastig
oder ausprobieren mit einigen Spielen welche sich mit den herkömmlichen crunchern kaum verkleinern lassen...
Ne, so mein ich das nicht...
Wie groß sind die Entpacker vom Exomizer oder PUCrunch? Der Platz des Decrunchers sollte ja (möglichst) nicht überschrieben werden, die zu packenden Daten dürfen also eine gewisse Größe nicht überschreiten. Wenn das nicht reicht, dann braucht es halt was möglichst kleines, was nicht so stark packen muss, aber zumindest auf diese Größe packt. Ein RLE, der weniger als $33 braucht, ist prima. Aber was, wenn RLE nix bringt? Was wäre dann der nächst-kleinste Code, der vielleicht doch liefern kann?
-
hmm. Muss dann schon ein LZW derivat sein (sequenzpacker) Aber alleine durch Videoram und Charsets kann man immer was mit RLE
packen.
Der LZW muss extrem klein sein damit möglichst viel Platz für das Dekompr. Spiel bleibt
Vielleicht kann man den Exo zwingen nur 4bit (16 Werte) wörterbuch zu nehmen . K.A
war da nicht so ein switch -m256 oder -p 256 ? habs vergessen
vielleicht geht -m16 auch aber er schrieb in der Doku (martin) das diese schalter das compressat grösser machen also schlechter packen
> Du spricht etwa von Videodaten ? Die lassen sich ja schwer pressen wenn viele Pixel (details) im Bild sind..
-
Hier ist das Ziel, $0200 bis $ffff zu entpacken, oder?
Ein mehr als ordentlicher Sequenzpacker (ZX0, im Mittel genauso crunchy wie Exomizer) passt locker in den Stack.
-
Hier ist das Ziel, $0200 bis $ffff zu entpacken, oder?
So hatte ich das auch verstanden: alle genannten Beispiele lassen sich mit exomizer oder auch vielen anderen Packern lösen.
Interessant wäre es aber schon mal, die $33-$FFFF zu unterbieten Geht in meinen Augen nur mit RLE. Dabei sollte geklärt werden, wie der Ausgangszustand bei Übergabe sein muss.
-
Wär akademisches Code Golf, ohne wirklichen praktischen Nutzen.
(Und die $33 wurden ja auch nur erreicht, indem der minderwertige langsamere Escape-Byte-Ansatz genutzt wurde statt des Typ+Zähler-Byte-Ansatzes.)
-
Hier ist das Ziel, $0200 bis $ffff zu entpacken, oder?
Ein mehr als ordentlicher Sequenzpacker (ZX0, im Mittel genauso crunchy wie Exomizer) passt locker in den Stack.Krill Hast Du Dir den mal oben angehängden Link mal angesehen ?
-
Hast Du Dir den mal oben angehängden Link mal angesehen ?
Den Link zu Plush Packer? Ja, warum?
-
Hast Du Dir den mal oben angehängden Link mal angesehen ?
Den Link zu Plush Packer? Ja, warum?
Hier ist das Ziel, $0200 bis $ffff zu entpacken, oder?
Weil Du nach dem oben zitierten Ziel gefragt hast, und das verlinkte Programm das kann, sogar ab $0033 .
-
Weil Du nach dem oben zitierten Ziel gefragt hast, und das verlinkte Programm das kann, sogar ab $0033 .
Ich finde nur fragwürdig, diese $33 unterbieten zu wollen.
Und das verlinkte Programm habe ich damals gebaut, bevor ich mir einen neuen Nick ausgeguckt habe.