Lethargeek Kompakt - компрессор ZX-графики [Архив] - Speccy

Lethargeek

30.05.2015, 09:55

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

(удолил как неактуальную)

Lethargeek

05.06.2015, 11:21

и чавойта все скачавшие отмолчались...
у меня щас в последней версии (монохром) выигрыш супротив LC до ~700 байт
например MAC/Phantis 5238 против 5937 (из проверенных эта самая плохопакуемая вообще)
в среднем разница ближе к 300-500, проиграл (до 30-40) в основном на некоторых ингеймах
самый крупный аномальный проигрыш на картинке catmans gallery4 (ажно целых 165 байт)
я подозреваю, что из-за перевёрнутых повторений, но что-то мне симметрию делать влом

Hrumer

05.06.2015, 12:38

Тестил тоже на Phantis. Еще были мотоциклы, firefly, fantastic dizzy. Везде lgk показывал лучшие результаты. Lgk-xored.bmp очень интересно было смотреть, как пропадает рамка, диззи и другие повторяющиеся элементы.
Эти элементы находятся только по точному совпадению байтовому, или анализируется, что может быть сдвиг по горизонтали?

---------- Post added at 15:38 ---------- Previous post was at 15:32 ----------

у меня щас в последней версии (монохром) выигрыш супротив LC до ~700 байт
например MAC/Phantis 5238 против 5937 (из проверенных эта самая плохопакуемая вообще)
в среднем разница ближе к 300-500, проиграл (до 30-40) в основном на некоторых ингеймах
самый крупный аномальный проигрыш на картинке catmans gallery4 (ажно целых 165 байт)
я подозреваю, что из-за перевёрнутых повторений, но что-то мне симметрию делать влом

Ого, в той версии, что была выложена - phantis зажался до 5502. Стала 5238. Серьезное улучшение!

Думал, в LC5.2.1 добавить ключ, чтобы без атрибутов паковал. Но пока не сделал.

Lethargeek

06.06.2015, 05:58

xored получается так: каждую клетку-знакоместо можно инвертировать или кcорить на соседние со сдвигом 1-2 пикселя (вычищает сплошные заливки и типичные текстуры) или на любую прошлую (мб инвертированную) клетку. Сдвиги не учитываются сейчас, всё равно для фоновых объектов один обычно, так что и со сдвигом будет много одинаковых клеток. Совпадения точные не требуются, лишь бы разница поменьше была, в любом случае выбор в пользу ксорки, занимающей меньше места в префиксном коде (код простой фиксированный оставил, потому что подгоняется под него и разница с оптимальным хаффманом незначительна; в общем лучше, если больше нулей получится). Так что нужно будет еще запомнить инфу о выборе (вот она кодируется по хаффману, потому что непредсказуема) плюс, возможно, расстояние для ксорки с далёкой клеткой (кроме совпадения с прошлой ссылкой в случае крупных фоновых объектов или везения). По уму надо бы после обработки всего экрана еще раз сравнить размеры и скорректировать, но пока я этим не занимался. Цель была определиться сперва с форматом. Монохромный пакер новый улучшенный выложу, наверно, в понедельник, потом буду атрибутами заниматься, а потом депакером на z80.

---------- Post added at 05:58 ---------- Previous post was at 05:56 ----------

Ого, в той версии, что была выложена - phantis зажался до 5502. Стала 5238. Серьезное улучшение!
а всего-то сделал необязательной кодировку для пустых четвертушек :D
всё равно их получается маловато даже после ксорки в таких картинках

Думал, в LC5.2.1 добавить ключ, чтобы без атрибутов паковал.
надо чтобы с заданным значением атрибута

Lethargeek

08.06.2015, 12:34

вотъ последняя нецветная версия, дальше буду с атрибутами уже делать
дольше думает, бо сперва считалка множество конфигураций перебирает
запилил еще один режим группировки (проигрыш на кэтмэне меньше стал)
и поправил упаковочную стратегию, где-то пару дюжин байт может выгрызть
плюс добавил вывод непонятной статистики))

(удолил)

Lethargeek

18.06.2015, 17:22

Вот и полностью функциональная пц-версия. Способ упаковки атрибутов по результатам тестов избран простой, вариантов действий на каждом три: повторить соседа по горизонтали или по вертикали, или загрузить новый (непосредственно или из короткого словарика самых частых). Один бит при повторе прошлого действия и два бита при несовпадении с ним (плюс возможная загрузка - несколько бит). Итого не меньше бита на атрибут, что невыгодно лишь в случае совсем простых и сильно регулярных раскрасок. Делать счетчики повторов пока не стал, и так проигрыш LC по атрибутам бывает редко, а со всей уже запиленной ерундой мне еще придётся взлетать на спектруме :)

В целом по результатам тестов 320 картинок и заставок (без ингеймов) с zxart.ee:
средний выигрыш у LC - 454 байта и 11-12% (по атрибутам - 54 байта и даже 18%)
самый крупный абсолютный выигрыш: MAC - Livingstone Supongo (877 байт)
самый крупный относительный: Chris Graham - Judge Anderson (19.5%)
средняя степень сжатия от 6912 уже почти 50% :cool:

проиграл всего в 5 картинках из этих 320 (и еще в 7 меньше сотни байтиков выиграл):
CatMan - catmans gallery4 (-93 байта) -- отражения по вертикали (орнамент рамки)
A-Graph - 3.5FLOP (-102 байта) -- множество скрытых повторений, простая раскраска
Rindex - Сетка 3 (-117 байт) -- множество регулярных повторений (в раскраске тоже)
Lizard, Slider - Alien Syndrome (-143 байта) -- имитация комодурского лоуреза
(просто не предусмотрел подобного извращения, не подумал как-то)))
Shiru - City Storm 1k gfx (-268 байт) -- монохромная диффузная конверсия
что интересно, в целом по диффузным картинкам результаты непредсказуемы
прогнал несколько сконверченных фотографий - хуже или лучше, как повезёт
в принципе понятно, что делать с ними - например, несколько префиксных кодов
ведь во многих клетках только 2-3 вида (в смысле усреднённой "яркости") чанков
также многим спектрумовским картинкам (и тому же лоурезу) не повредило бы
как-нибудь потом допилю, или уже с новым форматом только...

по ингеймовым картинкам средний выигрыш только 8-9% и чаще проигрыши
в них больше регулярности в раскраске и длинных повторяющихся полосок
да и в целом упакованный размер поменьше, и меньше разница
правда, я пока ингеймов смотрел немного

(del/45)

drbars

03.09.2015, 09:01

Lethargeek, депакер под z80 имеется?

Lethargeek

13.09.2015, 18:28

drbars, пока некогда, делал только пробные процедурки

drbars

14.09.2015, 11:34

Lethargeek, жду тогда :) Общий размер картинки обычно всегда определялся депакер+данные. Жмёт довольно круто, не бросай проект :)

Lethargeek

04.12.2015, 18:06

Дошли руки наконец позаниматься zx-депакером. Пока сделал для проверки имитацию распаковщика монохромных мотоциклов (3194 байта без заголовка). Даже без атрибутной части размер вышел нефиговый, под 300 байт (но я уже наметил, как на 30-40 байт сократить). Время распаковки ~60 фреймов.

Lethargeek

08.12.2015, 09:20

Ну, вот как-то так оно может выглядеть - (del)

Итого 3767 байт с пришитым депакером, разница с исходным сжатым файлом 369 байт (сам депакер больше, но в него вливается заголовок). Многовато, но возможно чутка подсократить, изменив слегка формат сжатых данных, и сделав распаковку атрибутов в конце отдельно. Также можно несколько улучшить уровень сжатия, корректируя кодовое дерево (без депакера подразумевается фиксированное)

Hrumer

08.12.2015, 10:34

Достаточно быстро и красиво распаковывает!

drbars

08.12.2015, 11:52

Lethargeek, исходный текст депакера можешь опубликовать?

jerri

08.12.2015, 14:14

у меня вопрос
для такой простой картинки 3767 байт это не много ли?

drbars

08.12.2015, 16:07

jerri, ты сравнивал с другими пакерами?

Lethargeek

08.12.2015, 19:15

исходный текст депакера можешь опубликовать?
а смысл? он же не для всех картинок подходит, это лишь набросок для оценки перспектив автогенерации
могу в личку кинуть, кому интересно, но сначала причешу и откомментирую

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

для такой простой картинки 3767 байт это не много ли?
а как надо? ;)
http://savepic.ru/6154971.png
LC сжал в 4222 с депакером

jerri

08.12.2015, 22:15

Lethargeek, да просто странным показалось... много залитых полей, а сжатие не очень.

drbars

09.12.2015, 14:26

Lethargeek, ждем тогда оптимальный упаковщик на PC. Думаю атрибуты лучше распаковывать отдельно, чтобы вывод был визуально быстрее.

Lethargeek

10.12.2015, 04:22

ждем тогда оптимальный упаковщик на PC
я еще из этого не всё выжал (на 6 байт укоротил депакер еще сегодня) ;)

Думаю атрибуты лучше распаковывать отдельно, чтобы вывод был визуально быстрее.
буду делать разные варианты, а то вдруг кому-то так больше нравится
вот не знаю только, есть ли смысл для "удобных" адресов отдельный депакер делать
пока пилится универсальный и безопасный, для сборки под любой адрес

Lethargeek

12.12.2015, 11:18

Вариант с отдельными атрибутами и слегка подправленным форматом (3749 байт) - (del)

Lethargeek

15.12.2015, 15:39

ж0стко извратившись, удалось ужать мотоциклы до 3736
также запилил еще посложней картинку из бывших здесь
и бонусом - слайдшоу из этой пары

дальше, видимо, пока возьму перерыв
кому будет интересен исходник - пишите в личку
(но сразу не отправлю, почистить надо)

(del/12)

drbars

15.12.2015, 15:57

Lethargeek, депакер универсальный есть?

Lethargeek

15.12.2015, 16:20

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

Bedazzle

15.12.2015, 16:45

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

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

Lethargeek

15.12.2015, 16:51

Bedazzle, "графику" включает и спрайты тоже :) (особенно маски хорошо сжиматься должны)

drbars

15.12.2015, 20:49

Bedazzle

15.12.2015, 21:33

Bedazzle, "графику" включает и спрайты тоже :) (особенно маски хорошо сжиматься должны)

ме-га-су-пер

Lethargeek

15.12.2015, 22:35

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

drbars

17.12.2015, 07:34

Lethargeek, лучшее, как говорится, враг хорошего :)

Lethargeek

17.12.2015, 10:49

интереса ради набил спрайтами отсюда (http://zx-pk.ru/showthread.php?t=25929&p=846536#post846536) один экран
при запрете дальних ксорок - на треть ужались
при разрешённых дальних ксорках - больше чем наполовину
а поскольку фазы одного спрайта требуются вместе обычно
то "наполовину" ближе к вероятному результату

goodboy

17.12.2015, 12:51

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

Lethargeek

11.01.2016, 07:15

допилил за праздники генератор, просьба потестировать поактивнее
в качестве входных параметров sfxpack - имя файла и адрес запуска на спеке
(адрес с минусом изменяет способ упаковки атрибутов на смешанный)
на выходе пока что голый бинарь, может быть, когда-нибудь тапку сделаю
а пока что грузите в память эмуля по указанному адресу и randomize usr
в редких случаях при повторном запуске может быть замусоривание картинки
это не баг, это фича) но сообщайте, если встретится, всё равно

(del/11)

drbars

11.01.2016, 10:06

Lethargeek, у меня Symantec Download Insight заматерился :) Картинка нового Диззи упаковалась лучше.

LC5: dizzy_final.lc5 -- 5642 байта
LGK: dizzy_final.lgk -- 5095 байт

547 байт выигрыш! :v2_dizzy_roll:

Упаковку по третям опциональную можешь добавить?

Hrumer

11.01.2016, 11:54

drbars

11.01.2016, 12:01

fantasyworld dizzy:
С депакерами:
LC521: 3791
LGK016: 3517

274 байта выигрыш, это отличный результат!
drbars, 547 байт это очень крутой выигрыш. Упаковка была с депакерами? Использовался LC521?
В эмуле распаковывается нормально.
Да, с депакерами. Всё проверил, распаковка в норме. Картинка очень перегруженная от MAC'а.

Titus

11.01.2016, 12:53

Теперь drbars впихнет еще пару комнат в свою игру без проблем, верно?)

Lethargeek

11.01.2016, 17:45

Упаковку по третям опциональную можешь добавить?
по третям зачем? упаковка же познакоместная у меня
будет обработка любых окошек (только неизвестно когда))

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

Картинка очень перегруженная от MAC'а.
да, у депакера еще такая особенность - для перегруженных плохосжимаемых картинок он меньше :)

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

еще несколько наблюдений и замечаний - в силу упомянутой особенности и вообще
так как мой депакер в среднем байт на 200 длиннее лазерного - проигрыши sfx вероятнее
в основном на сильно сжимаемых картинках, где много пустоты, заливок и повторений
(впрочем, далеко не на всяких, контрпримеры: FDThorpe - Convoy, Einar - Elexis)

кроме этого, проигрыш даже без депакера вероятен в случаях "ненормальной корреляции"
это если по какой-то причине корреляция между произвольными соседними пикселями слабая
но сильна корреляция отдельных пикселей в байте, в результате на участках картинки
получаются ограниченные наборы байтов, соответственно с ограниченным числом сочетаний
Shiru Citystorm - как выяснилось, оригинал до диффузии состоял из "пикселей" 8x1
также ранее упоминавшийся Alien Syndrome (lowres - лишь 16 байт почти на всю картинку)
но самый патологический случай (проигрыш 747 байт без депакера!) был R-Tape - EFMB
почти по всей площади (кроме центра) корреляции между соседними пикселями нет вообще!
нет двух совершенно одинаковых знакомест! но зато зеркальная корреляция внутри байта
в результате на 3/4 картинки тоже видим только 16 различных байт (но уже без заливок)
и самое смешное, что JBIG на ней проиграл обоим спектрумовским компрессорам)))

так что применяйте оба как взаимодополняющие :v2_dizzy_roll:

drbars

11.01.2016, 20:44

Теперь drbars впихнет еще пару комнат в свою игру без проблем, верно?)
Комнаты крайне плохо жмутся... Сам формат описания спрайта довольно оптимальный. Так что запихиваем, куда пихается :D

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

Lethargeek

11.01.2016, 21:15

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

Lethargeek

14.01.2016, 20:18

каждый раз, возвращаясь к своему коду, понимаю, насколько сжатие далеко покамест от оптимального
применил однократную коррекцию после хаффмана с перевыбором типа ксорки с учётом длин кодов
выигрыш на разных картинках получил от нескольких байт до нескольких десятков байт
(эталонные мотоциклы уже только 3710); и несколько ускорил компрессор

(del/20)

drbars

14.01.2016, 20:38

8 байт выигрыш! ура!

Lethargeek

16.01.2016, 12:22

важно! предотвращена возможная в редких случаях фатальная порча системной области бейсика-128
также устранил причину, по которой при повторном запуске некоторые картинки могли замусориться
(никаких корректирующих pokes теперь не нужно)

(del/12)

Barmaley_m

17.01.2016, 14:34

Прошу прощения, если боян, но: почему Хаффман? Почему не арифметическое кодирование?

Vitamin

17.01.2016, 17:25

Почему не арифметическое кодирование?
А есть быстрый вариант без умножений-делений?

Lethargeek

17.01.2016, 21:17

и короткий)

Lethargeek

22.01.2016, 07:45

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

и, наверно, дальше в блог переберусь с обновлениями
а то влез тут нагло в чужую тему :)

(del/44)

Bedazzle

22.01.2016, 07:59

и, наверно, дальше в блог переберусь с обновлениями

Так может, просто открыть новую тему чисто по своему пакеру?
По мне, блоги - какая-то лишняя фича. :/

Lethargeek

23.01.2016, 05:35

посмотрю, что с блогом будет получаться, а там решу

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

drbars, а ты оптимизатор применяешь перед компрессией?
можно дополнительно выиграть и поболе нескольких байтиков

drbars

23.01.2016, 12:17

drbars, а ты оптимизатор применяешь перед компрессией?
можно дополнительно выиграть и поболе нескольких байтиков
Какой такой оптимизатор? Версия 0.22, как и 0.19, дала размер файла на 1 байт меньше 0.18. Режим атрибуты отдельно, ключ "-32768"

Lethargeek

23.01.2016, 15:03

Какой такой оптимизатор?
ты что, ветку не с начала читал? посмотри посты с номерами 36 - 40
например, Фантис МАКа с автооптимизацией похудел на целых 45 байт
а ведь можно еще ручками оптимальную раскраску пробовать подбирать
инвертировать отдельные тайлы так, чтобы резких переходов было поменьше
я потом, наверно, свой оптимизатор буду пилить, но и этот тоже весьма полезен

Режим атрибуты отдельно, ключ "-32768"
эээ? с минусом как раз НЕ отдельно же

drbars

23.01.2016, 15:53

Lethargeek, после оптимизации выигрыш в 38 байт.

Lethargeek

23.01.2016, 18:27

drbars, смотри только, чтоб невидимые надписи не пропали (а то вдруг автор подписался, а ты убрал)

drbars

23.01.2016, 23:17

Lethargeek, я не проверял... как депакер с прерываниями дружит?

Lethargeek

23.01.2016, 23:55

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

Eugene85

14.02.2016, 13:15

А есть быстрый вариант без умножений-делений?
А это точно проблема? Кто-нибудь пробовал на практике?

Vitamin

14.02.2016, 22:19

А это точно проблема? Кто-нибудь пробовал на практике?
Точно. Я пробовал. ~4кб/с скорость распаковки.

Lethargeek

15.02.2016, 00:35

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

Lethargeek

04.08.2016, 00:58

Сократил длину некоторых веток zx-депакера, новые sfx-экраны могут стать на 2-33 байта меньше (но обычно 9-12 байт). Размер самого упакованного экрана остался тем же, только иногда может поменяться порядок битов.

Отдельный zx-депакер (для всего экрана) почти готов, осталось только дотестировать и запилить аналогичный пц-депакер с новым форматом заголовка. Потом буду заниматься универсальным (де)пакером спрайтов / произвольных прямоугольников.

(del/29)

drbars

08.08.2016, 14:05

По поводу произвольных прямоугольников. Например есть 4 картинки. Если каждую отдельно пожать, то объём в сумме больше на 500 байт, чем при сжатии всех этих картинок помещенных на один экран.
Собственно вопрос, можно ли сделать так, чтобы из общего потока достать нужный прямоугольник и вывести на экран и т.о. при сжатии учитывать весь дамп спрайтов?

Lethargeek

08.08.2016, 20:56

Например есть 4 картинки. Если каждую отдельно пожать, то объём в сумме больше на 500 байт, чем при сжатии всех этих картинок помещенных на один экран.
В смысле, "каждую отдельно пожать", на полупустом экране одна картинка?

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

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

Lethargeek

26.08.2016, 08:21

Ну, типо, релиз. Теперь можно с единицы нумеровать. :)

Новый пакер сохраняет в новом формате, пригодном для распаковки универсальным z80-депакером (исходник в SjAsm прилагается, можно вставить в какой-нибудь БолееЛучшийВью)) Сжатие немного улучшено, но заголовок тоже распух, так что сжатые экраны могут быть как чуть больше, так и чуть меньше, чем в старых версиях. Универсальный z80-депакер создан на основе sfx-модулей, хоть и отличается кое-чем (не считая добавленного парсера заголовка). Он немного медленнее и значительно жирнее типовых размеров sfx-кода, но зато по-прежнему не требует запрета прерываний, совместим с бейсиком, не использует альтернативные регистры (кроме af'). Так что есть резервы на сокращение для каких-то специфических применений. Запланированный распаковщик спрайтов, вероятно, также может получиться поменьше (правда, от формата спрайтов тоже зависит). Корректность заголовка z80-кодом не проверяется! Так что на случайных или битых данных сбросится или повиснет, или незаметно испортит память.

В песюковый (де)компрессор я примитивную (лишь бы из массивов потом не вылезти) проверку заголовка добавил. Да, екзешник теперь один, управляется аргументами командной строки. Полный парсер мне писать было лень, так что пользуйтесь bat-скриптами для групповых операций и сложных преименований (примеры приложены). Запуск без параметров выдаст список команд и опций. Исходники пока не отдам (слишком уж страшны)) может, вовсе перепишу всё заново).

Просьба сообщать об ошибках. Качать из блога:
http://zx-pk.ru/entries/9-lethargeek-kompakt-last-version-download.html

Bedazzle

26.08.2016, 09:57

Запланированный распаковщик спрайтов

Он следующий на очереди, или ещё что-то есть?

Lethargeek

26.08.2016, 19:54

Bedazzle, первым в очереди переписывание пц-пакера ради лучшей модификабельности его. Дальше без определённого порядка, по вдохновению, - оптимизатор картинки, спрайты, несколько мелких улучшений. Еще надо представление форматов спрайтов продумать же.

Bedazzle

27.08.2016, 09:06

Еще надо представление форматов спрайтов продумать же.

Что-то можно украсть у Jerry из его Cutter-а.

drbars

07.02.2017, 08:14

Lethargeek, Давно нет новостей. Будут новые фичи или уже не ждать? :)

Lethargeek

07.02.2017, 14:07

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

Bedazzle

07.02.2017, 18:26

будут, но не знаю когда :( экспериментирую помаленьку

ждём-ждём :)

Lethargeek

22.04.2017, 15:56

"Оптимизатор Атрибутов Летаргика" версия 1.0

От аналогичного продукта Screen Optimizer by g0blinish & Den Popov отличается более удобным (мне))) интерфейсом редактирования, а также алгоритмом автооптимизации (сокращает общее количество атрибутов, убирает неиспользуемые цвета). Алгоритм экспериментальный, но результаты неплохие. Заточен под мой Lethargeek Kompakt v1.1 (предпочтение горизонтальным полоскам одинаковых атрибутов), но и для других компрессоров полезен, так как старается привести одноатрибутные области к наиболее близкой к прямоугольной форме.

Сделано в mingw на C + SDL2 (dll включена), кодить диалог для файлов мне было влом, так что имена входного и выходного файлов задавайте как параметры командной строки.

Просьба сообщать об ошибках, особенно если в выходном скрине где-то вдруг изменятся видимые цвета (в самом редакторе этого не видно, цветной скрин там генерится только при старте).

Качать из блога: http://zx-pk.ru/entries/209-opal-last-version-download.html

Shiny

22.04.2017, 16:19

Было бы интересно увидеть сам алгоритм.

Lethargeek

22.04.2017, 16:39

Было бы интересно увидеть сам алгоритм.
он еще меняться будет скорей всего, я пока что не вполне доволен его работой

NEO SPECTRUMAN

22.04.2017, 18:05

А есть что то с расчетом именно на скорость распаковки а не на уровень сжатия?

Lethargeek

22.04.2017, 22:25

за скоростью - это к побайтовым упаковщикам, их вроде бы хватало всегда)

shurik-ua

23.04.2017, 02:33

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

Shiny

23.04.2017, 08:53

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

Lethargeek

24.04.2017, 04:46

и при чём тут энтерпрайз вообще?..

Shiny

24.04.2017, 05:44

и при чём тут энтерпрайз вообще?..
а причем тут побайтовые упаковщики?

Lethargeek

24.04.2017, 12:53

а причем тут побайтовые упаковщики?
:v2_dizzy_facepalm: при том, что они работать могут быстрей почанковых (и других, у которых также "символ" с байтом не совпадает)

drbars

10.05.2017, 05:09

Lethargeek

10.05.2017, 13:17

Bedazzle

10.05.2017, 14:12

drbars, я не знаю, когда время найду заниматься темой как полагается, мозг перенастроился на другое

т.е. спрайты не ждать? :v2_down:

Lethargeek

11.05.2017, 01:40

Bedazzle, полноценной и универсальной утилиты не скоро ждать, но если тебе нужно что-то частное-конкретное, пиши в личку, может, и получится быстро сделать

drbars

17.05.2017, 09:53

drbars, я не знаю, когда время найду заниматься темой как полагается, мозг перенастроился на другое
могу пока склепать отдельную утилиту, обрезающую уже упакованную картинку снизу на любое кол-во тайловых строк
Как это будет работать? Скажем есть картинка размером 256х384 (двойная). Нужно, например, распаковать либо одну, либо другую. Словарь для обеих картинок общий. Или скажем распаковать с 1-6 строки (32*6 строк со смещением 0 знакомест), или (1 строку со смещением 32*24 знакомест) например. Режим ч/б без атрибутов или с цветной? Распаковка линейная или на экранную область.

Фишка заспаковщика, быстро вынуть нужные данные, не разворачивая весь массив.

Lethargeek

17.05.2017, 17:55

Как это будет работать? Скажем есть картинка размером 256х384 (двойная). Нужно, например, распаковать либо одну, либо другую. Словарь для обеих картинок общий.
в этом случае проще сжать картинки раздельно, заголовок только 23 байта

"словарь" - тайлы, распакованные раньше, доступные для чтения на экране (или в буфере, куда идёт распаковка)
потому, если тебе нужно доставать графику маленькими кусками, то пока только таким способом:
подготовить скрин, где всё нужное прижато к верхнему краю, упаковать его целиком
от упакованного файла этой временной спецутилитой откусить ненужные строки
потом этот верхний обрезок можно будет распаковывать куда надо, с атрибутами или без

Bedazzle

17.05.2017, 20:43

Bedazzle, полноценной и универсальной утилиты не скоро ждать, но если тебе нужно что-то частное-конкретное, пиши в личку, может, и получится быстро сделать

Не, пока ради меня не нужно дёргаться, я на будущее загадываю. Сейчас использую Эйнаровский пакер, но надеюсь, что потом можно будет переехать. :)

drbars

18.05.2017, 06:12

Скорее всего придётся отказаться, если пакером жать вставочные спрайто-картинки отдельно он проигрывает Optimal Hrust и в размер и в скорости. Нужен алогрим который умеет вынуть нужные данные из упакованного без буфера.

Lethargeek

18.05.2017, 15:01

drbars, какого размера эти вставочные спрайто-картинки? вышли мне конкретный пример, не верю; и вынимать куда, сразу на экран?

Bedazzle

24.02.2025, 13:18

Несколько реквестов к упаковщику:
— возможность выбора для сжатия одной из 1/3 или 2/3 экрана на выбор с атрибутами и без.
— возможность упаковки графического ковра произвольного размера, с возможностью выборочной распаковки в линейный буфер (заданное смещение, длина).

Сейчас пытаюсь ужать графику Johnny Bravo - Run Johnny Run в две банки, - чуть-чуть не утаптывается. И тоже интересны неполные экраны (две верхних трети), и даже без атрибутов.

самый лучший результат - Lgk - 34318 байт
второе место - rcs+zx0 - 34490 байт (rcs+zx5 ещё дожимаю, но по всей видимости, результат будет близок к rcs+zx0)
upkr даёт дикие 38019 байт, да ещё и 320 буфера требует