Сжатие данных

[Improver]

когда ты преобразовывал исходник для себя сделал одну неправильную замену

Спасибо, исправил. Эту подпрограмму я скопировал из РДС, и там та же ошибка, но, наверно, повезло -- в РДС она себя не проявила...

[Advertiser]

[ivagor]

Если в сжатом файле нет последовательностей литералов>255 байт (как вероятно в РДС), то проверка старшего байта счетчика будет обойдена (и в распаковщике таких файлов ее можно даже удалять).

- - - Добавлено - - -

Кстати, если углубляться, то такую статистику упаковщик выдает по ключу -stats

[ivagor]

Могу, но с тех пор появился сжимающий сильнее zx0 (еще удобнее salvador). Исходники распаковщика для 8080 можно взять здесь (мнемоники z80) или здесь (мнемоники 8080).

[CityAceE]

ivagor, спасибо! Действительно, поэкспериментировал, и zx0 дал большую компрессию.

Набор экранов в уровне 30 экранов по 800 байт. Каждый экран сжимался отдельно.

Без сжатия - 24000 байт
LZSA1 - 12443 байта
LZSA2 - 11460 байт
ZX0 - 10851 байт

А исходники распаковщика нашёл как раз у Дениса Грачёва в нужной мне мнемонике Z80 Где-то в подсознании осело, что он именно ZX0 использовал в своих играх.

[Titus]

Набор экранов в уровне 30 экранов по 800 байт. Каждый экран сжимался отдельно.

Попробуй сжимать и распаковывать по 2 или 4 экрана. Если промежуточный буфер позволяет где-то в памяти. Может оказаться интереснее результат.

[ivagor]

Если есть место для распаковки сразу трех экранов, то можно попробовать паковать по одному но RIPом (и ему еще понадобится рабочая область в районе полутора килобайт). Он конечно медленнее распаковывает, но для 800 байт это не критично.

[ivagor]

Все же на отдельных фрагментах по 800 байт RIP может и проиграть. Тут скорее подойдет exomizer. Крупные файлы он сжимает хуже RIP, но
1. Рабочая область всего 256 байт вместо полутора килобайт. Если сжимать по несколько уровней, то скорее всего получится группировать по столько же, как и с zx0 (в худшем случае на один меньше).
2. Есть режим сжатия -E с общим "словарем", в данном случае он как раз может подойти.

[CityAceE]

А вот такой вопрос, опять же применительно к моей ситуации. Например, у меня есть непрерывный бинарник, содержащий в себе 30*800 байт = 24000 байт. Мы его целиком сжимаем. А потом как-то дополнительно проходимся по нему, получая адреса где начинаются сжатые данные для каждой комнаты. И когда нужно, мы указываем на адрес с сжатом массиве и сколько байт начиная с этого адреса нужно распаковать. Я не особо изучал методы сжатия, и скорее всего так нельзя делать, но спросить на всякий случай решил. Наверное, это получается что-то типа сжатия каждой отдельной комнаты, но с общим словарём. Но может быть если оно всё идёт единым блоком, то это как-то может благотворно повлиять на степень сжатия?

[ivagor]

Если правильно понимаю, ты про "поточный" распаковщик с кольцевым буфером ("окном"). Современные упаковщики в основном умеют сжимать в расчете на это, например salvador для zx0 (опция -w).
Упаковываем файл целиком, а распаковываем последовательно частями по мере необходимости. Размер буфера удобно выбирать по степеням двойки - 16,32,...,256,...,1024 и т.д. байт. У svofski есть готовый распаковщик zx0 для окна 256 байт (и у меня вроде есть, но у svofski он давно выложен в открытый доступ), что в данном случае мало, его надо модифицировать в бОльшую сторону.

[svofski]

svofski он давно

Наверное вот это можно адаптировать, если буфер 256 байт: https://github.com/svofski/v06c-prog...0_chunk256.asm

Но для уровней интересно было бы попробовать составить общий словарь.