Сжатие и упаковка. hrum3.5, hrust1, hrust2, laser compact x.x.

[Alexandr Medvedev]

А где лежит упаковщик на PC в LC5?

Здесь не оно?
http://zx-pk.ru/showpost.php?p=22982&postcount=18

[Shadow Maker]

Ну я имел ввиду скомпилированный продукт под windows, чтобы можно было пользоваться. Может скомпилируешь лазер компакт? Хруст есть от psb.

[Hrumer]

Погодите чуток, приаттачу депакер и выложу завтра-послезавтра.

По картинке с мотоциклами такая ситуация:

LC5.2 на ZX: 4254
Новый LC5.2.1: 4156

После Screen Optimizer:

LC5.2 на ZX: 4152 (4143, если оптимизацию несколько раз применить)
Новый LC5.2.1: 4050 (4042, если оптимизацию несколько раз применить)

[goodboy]

После Screen Optimizer:

там кстати оптимизацию можно несколько раз применить, иногда ещё что-то правится.
(на мотоциклах смотреть верхний правый угол)

[Alexandr Medvedev]

Ну я имел ввиду скомпилированный продукт под windows

Лови.

[Hrumer]

Если это просто скомприлированный исходник Никиты Бурнашева, то он сохраняет файлы без заголовка(и без кода картинки) и без депакера. Плюс поймал баг, при дистанции ровно #300 некорректно код записывается при длине 3 и более. При длине = 2 этот вариант отбрасывается. Надо поправлять дистанция >= 0x300 на дистанция > 0x300 в трех местах.


Апдейт:

Добавил депакер. Готово.
Сжатие лучше, чем оригинальный ZX Laser Compact 5.2 на 30-110 байт.

[Advertiser]

[Barmaley_m]

Я думаю, что релоцируемость распаковщика - это расточительство. Нужно просто спросить пользователя о желаемом адресе размещения распаковщика, и настроить его код на этот адрес. Хоть пара байт - а будет сэкономлена.

Если есть возможность уменьшить размер распаковщика, пусть даже ценой его замедления - надо использовать. Для 1к/4к интр это существенно. Малый размер файлов сделает замедление незаметным. Если кому-то не нравится медленное и неравномерное появление картинки - то можно распаковать не в экран, а в другое место, а потом перекинуть данные лдиром.

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

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

[goodboy]

Я думаю, что релоцируемость распаковщика - это расточительство.

и скорее всего call на RET в пзу для определения адреса вызова, что многие неодобряют.

---------- Post added at 10:53 ---------- Previous post was at 10:49 ----------

Апдейт:

а полностью автоном можно сделать ?
а то начинается libgcc....dll не найдено

[Vitamin]

и скорее всего call на RET в пзу для определения адреса вызова, что многие неодобряют.

Из всех известных мне пакеров так делают только CompressorCode4. А вот экранные пакеры- так вообще все.

[Hrumer]

Скомпилил с нужной опцией. Теперь вроде не ругается на отсутствие библиотек.

Убрать релоцируемость ок - опционально, с ключом буду делать. И для медленного депакера тоже.

Отключение некторых особенностей - проигрыш 30-100 байт(отказ от перевернутого LZ). Попалась одна картинка, где улучшение 19 байт, но это особенная картинка, заставка компрессора MSP.

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