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

[goodboy]

даже не ожидал что оптимайзер который я использую оказался таким древним - 1994год.
(у меня все рабочии программы в снэпшотах для быстроты загрузки и заставку с копирайтами я давно не видел)



на тот момент это была достаточно мощная программа, 5 вариантов упаковки + красивый вывод картинки
(fade in/out)



сейчас LC 5.x сжимает лучше, но оптимизировав предварительно картинку можно выиграть в размере.

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

[Advertiser]

[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, если оптимизацию несколько раз применить)

[Lethargeek]

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

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

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

После Screen Optimizer:

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

это цифры уже все с пришитым депакером?
и рекорд для пакеров спекографики?
а то я прикинул тут один способ...
получается примерно 3500 байт

[Hrumer]

это цифры уже все с пришитым депакером?
и рекорд для пакеров спекографики?
а то я прикинул тут один способ...
получается примерно 3500 байт

Без депакера и без заголовка. Депакер релоцируемый ~150 байт.
Вроде как рекорд для депакеров, не использующих буфер.

Давай угадаю способ: перекодируем по столбцам в третях экрана, далее самый простой RLE, потом Exomizer2? Или другой? Вообще, для именно заставок, когда есть место для буфера, надо бы более крутой пакер сделать. Будешь делать?

[Lethargeek]

Давай угадаю способ: перекодируем по столбцам в третях экрана, далее самый простой RLE, потом Exomizer2?

Не. Принцип сам довольно тупой, никакого поиска даже нет (хотя можно при желании и добавить) - паковать не байты, а квадраты пиксельные префиксным кодом, начиная с минимального 2x2, потом группы из 4 соседних, дальше получается знакоместо (если очень много пустого места - можно укрупнять дальше). Важна хитрость - упаковка не исходного знакоместа, а его ксорки со сдвигом на пиксельную строку или столбец, что для большинства "нормальных" картинок очень сильно увеличит кол-во пустот и перекосит вероятности вхождений непустых чанков. Недостаток - плохо пакуются текстуры, если их особо не обрабатывать (но пока я этим не занимался). Атрибуты жмутся по своим правилам, со сравнением с предыдущим по строке или по столбцу (что переключается на ходу).

Или другой? Вообще, для именно заставок,

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

когда есть место для буфера, надо бы более крутой пакер сделать. Будешь делать?

Пока пакер запланирован был только для песюка, но и до него еще далеко.
Я сейчас лишь на этапе экспериментов, только накропал на сях программку считать размеры.
Будет время - буду заниматься по настроению. Может, здесь еще идей каких-то подкинут...

[Alexandr Medvedev]

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

Лови.

[Hrumer]

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


Апдейт:

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

[goodboy]

После Screen Optimizer:

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

[Barmaley_m]

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

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

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

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