Архиватор с самым быстрым распаковщиком

[Titus]

А поделишься? Распаковщик попробую выдрать сам если не найдется у тебя в закромах.

Вот нашел дискету с исходником, которой сам пользовался для запаковки.

Краткая аннотация:
Выбор файла курсор джойстиком (8, 9), упаковка - клавиша 'C'. Файл сам упакуется и запишется обратно на диск. Клавишу '0' не нажимать, она отмечает файлы, как файловом менеджере, но это не используется. Упаковщик достаточно быстрый, хотя работает алгоритмом 'в лоб', простым поиском одинаковых фрагментов без всяких деревьев и т.д. Зато очень сильно оптимизирован по скорости. При упаковке файл загружается в конец 48кб-памяти, а упакованный файл пишется с начала памяти. Если они встретятся на середине... то файл не упаковался) Иными словами, очень большие файлы, упаковать нельзя. И еще, даже в финальной версии упаковщика нашел один баг из-за которого иногда(!) самый последний байт упаковывался неправильно. Не было времени и/или усидчивости с этим разобраться, и просто напросто записывал один лишний байт в конец исходного файла, или же после распаковки проверял, если файл совпадает с исходным, значит упаковалось правильно.

Краткая история:
Летом 1995 года, когда Софтстар предложил сделать Great Codemasters Collection, я решил сделать из этого конфетку, и помимо восстановления и обработки всех игр, сделать еще очень быстрый, но эффектный распаковщик. Чтобы раз - и игра очень быстро загрузилась и мгновенно распаковалась, в противовес набирающим тогда моду медленным депакерам с нудной надписью 'decrunching, please wait...'. На это и делался упор. В итоге, по тому времени (а может и до сих пор) это был самый быстрый распаковщик, а качество сжатия не меньше, а может и чуть больше, чем у популярного тогда архиватора Сендецкого LZSS. Так же следует преобразовать графику по столбцам, что дает максимальное сжатие, что так же сделано было в Great Codemasters Collection.
Кому интересно, можете загрузить любую игру из этой коллекции и посмотреть, как быстро она распакоывается, хотя после загрузки сперва идет распаковка, потом преобразование ВСЕЙ графики в игре из столбцового типа в нативный для конкретной игры формат.



p.s.: Как пользоваться TASM'ом 3.0:
C - каталог
W - загрузка файла (PROBA18)
A - ассемблирование
E - редактирование
R - запуск

p.p.s.: Исходник депакера не нашел, может он есть внутри исходника пакера, не листал. Но, в любом случае, он масенький и может быть найдет в любой моей игре после лета 1995 года.

[Titus]

Да, декомпрессор есть внутри.

---------- Post added at 03:10 ---------- Previous post was at 03:07 ----------

Кстати, из декомпрессора можно совершенно безболезненно выкинуть одну команду, при этом он будет работать так же. Подсказал в свое время Ивамото. Кто найдет, тому респект)

[Vitamin]

p.p.s.: Исходник депакера не нашел, может он есть внутри исходника пакера, не листал. Но, в любом случае, он масенький и может быть найдет в любой моей игре после лета 1995 года.

Он всегда использовался отдельно или были прецеденты приклеивания в начало сжатого блока (типа hrust/hrum etc)?

[Titus]

Он всегда использовался отдельно или были прецеденты приклеивания в начало сжатого блока (типа hrust/hrum etc)?

В основном отдельно, т.к. блоков для распаковки обычно бывало много, зачем хранить несколько копий распаковщика. А так можно сперва интро распаковать, потом картинку, потом игру. И все одним распаковщиком.

Распаковщик есть в исходнике, как отдельный фрагмент, даже помечен, что вот это распаковщик.

[newart]

Titus, а за счет чего распаковщик такой быстрый?

Результат оптимизации кода или данных?

[Titus]

Titus, а за счет чего распаковщик такой быстрый?

Результат оптимизации кода или данных?

Результат оптимизации как кода распаковщика, так и самого формата хранения данных, чтобы он был наиболее оптимален для быстрого извлечения из потока.

Т.е. сперва было прикинуто, что нужно два окна, длинное и короткое, размер которых, и длины копируемых фрагментов были бы оптимальны прежде всего для распаковщика, но при этом отвечали бы критериям хорошей упаковки данных.

А уже после распаковщика и утверждения формата данных был написан упаковщик.

[Hrumer]

M6:
and #c0
xor 2
просто на
and #c2?

[Titus]

M6:
and #c0
xor 2
просто на
and #c2?

А я не помню) Надо восстановить смысл декомпрессора, подписать комменты к исходнику, тогда станет понятно)

[Hrumer]

А можно и по другому - скомпилить, если на тестовых файлах, чем больше, тем лучше - пройдет, значит, возможно и да.

[Titus]

А можно и по другому - скомпилить, если на тестовых файлах, чем больше, тем лучше - пройдет, значит, возможно и да.

Это метод 'на авось', это не наши методы)