8 байт выигрыш! ура!
Вид для печати
8 байт выигрыш! ура!
важно! предотвращена возможная в редких случаях фатальная порча системной области бейсика-128
также устранил причину, по которой при повторном запуске некоторые картинки могли замусориться
(никаких корректирующих pokes теперь не нужно)
(del/12)
Прошу прощения, если боян, но: почему Хаффман? Почему не арифметическое кодирование?
А есть быстрый вариант без умножений-делений?Цитата:
Сообщение от Barmaley_m
и короткий)
устранил возможность появления нескольких ненужных байт в sfx-блоке
сжатие улучшено почти до теоретически возможного оптимального
(для данного набора фильтров и формата упакованных данных)
и, наверно, дальше в блог переберусь с обновлениями
а то влез тут нагло в чужую тему :)
(del/44)
Так может, просто открыть новую тему чисто по своему пакеру?Цитата:
Сообщение от Lethargeek
По мне, блоги - какая-то лишняя фича. :/
посмотрю, что с блогом будет получаться, а там решу
- - - Добавлено - - -
drbars, а ты оптимизатор применяешь перед компрессией?
можно дополнительно выиграть и поболе нескольких байтиков
Какой такой оптимизатор? Версия 0.22, как и 0.19, дала размер файла на 1 байт меньше 0.18. Режим атрибуты отдельно, ключ "-32768"Цитата:
Сообщение от Lethargeek
ты что, ветку не с начала читал? посмотри посты с номерами 36 - 40Цитата:
Сообщение от drbars
например, Фантис МАКа с автооптимизацией похудел на целых 45 байт
а ведь можно еще ручками оптимальную раскраску пробовать подбирать
инвертировать отдельные тайлы так, чтобы резких переходов было поменьше
я потом, наверно, свой оптимизатор буду пилить, но и этот тоже весьма полезен
эээ? с минусом как раз НЕ отдельно жеЦитата:
Сообщение от drbars
Lethargeek, после оптимизации выигрыш в 38 байт.
drbars, смотри только, чтоб невидимые надписи не пропали (а то вдруг автор подписался, а ты убрал)
Lethargeek, я не проверял... как депакер с прерываниями дружит?
не должно проблем быть ни с прерываниями, ни с бейсиком
перезапускабелен бесконечно и памяти нигде не испортит
А это точно проблема? Кто-нибудь пробовал на практике?Цитата:
Сообщение от Vitamin
Точно. Я пробовал. ~4кб/с скорость распаковки.Цитата:
Сообщение от Eugene85
плюс к тому для zx-экрана теоретический оверхед от хаффмана - до ста байт
а на практике обычно намного меньше - изменения в депакере больше схавают
Сократил длину некоторых веток zx-депакера, новые sfx-экраны могут стать на 2-33 байта меньше (но обычно 9-12 байт). Размер самого упакованного экрана остался тем же, только иногда может поменяться порядок битов.
Отдельный zx-депакер (для всего экрана) почти готов, осталось только дотестировать и запилить аналогичный пц-депакер с новым форматом заголовка. Потом буду заниматься универсальным (де)пакером спрайтов / произвольных прямоугольников.
(del/29)
По поводу произвольных прямоугольников. Например есть 4 картинки. Если каждую отдельно пожать, то объём в сумме больше на 500 байт, чем при сжатии всех этих картинок помещенных на один экран.
Собственно вопрос, можно ли сделать так, чтобы из общего потока достать нужный прямоугольник и вывести на экран и т.о. при сжатии учитывать весь дамп спрайтов?
В смысле, "каждую отдельно пожать", на полупустом экране одна картинка?Цитата:
Сообщение от drbars
Не, с этим новым отдельным декомпрессором для всего экрана так не получится, потому что распаковка со ссылками по всему уже отрисованному экрану осуществляется. Если уж совсем невтерпёж, довольно просто можно допилить до распаковки в буфер 2048/2304 байта, а уже оттуда кидать в экран. Но вообще я планирую отдельную утилитку, чтоб и сжимать любой кусок без лишних пустот, и разжимать куда угодно, в любой раскладке.Цитата:
Сообщение от drbars
Ну это, типа, заголовок (или часть его) с параметрами сжатия можно сделать общим сразу для нескольких, а разворачивать отдельно какой захочется.Цитата:
Сообщение от drbars
Ну, типо, релиз. Теперь можно с единицы нумеровать. :)
Новый пакер сохраняет в новом формате, пригодном для распаковки универсальным z80-депакером (исходник в SjAsm прилагается, можно вставить в какой-нибудь БолееЛучшийВью)) Сжатие немного улучшено, но заголовок тоже распух, так что сжатые экраны могут быть как чуть больше, так и чуть меньше, чем в старых версиях. Универсальный z80-депакер создан на основе sfx-модулей, хоть и отличается кое-чем (не считая добавленного парсера заголовка). Он немного медленнее и значительно жирнее типовых размеров sfx-кода, но зато по-прежнему не требует запрета прерываний, совместим с бейсиком, не использует альтернативные регистры (кроме af'). Так что есть резервы на сокращение для каких-то специфических применений. Запланированный распаковщик спрайтов, вероятно, также может получиться поменьше (правда, от формата спрайтов тоже зависит). Корректность заголовка z80-кодом не проверяется! Так что на случайных или битых данных сбросится или повиснет, или незаметно испортит память.
В песюковый (де)компрессор я примитивную (лишь бы из массивов потом не вылезти) проверку заголовка добавил. Да, екзешник теперь один, управляется аргументами командной строки. Полный парсер мне писать было лень, так что пользуйтесь bat-скриптами для групповых операций и сложных преименований (примеры приложены). Запуск без параметров выдаст список команд и опций. Исходники пока не отдам (слишком уж страшны)) может, вовсе перепишу всё заново).
Просьба сообщать об ошибках. Качать из блога:
http://zx-pk.ru/entries/9-lethargeek...-download.html
Он следующий на очереди, или ещё что-то есть?Цитата:
Сообщение от Lethargeek
Bedazzle, первым в очереди переписывание пц-пакера ради лучшей модификабельности его. Дальше без определённого порядка, по вдохновению, - оптимизатор картинки, спрайты, несколько мелких улучшений. Еще надо представление форматов спрайтов продумать же.
Что-то можно украсть у Jerry из его Cutter-а.Цитата:
Сообщение от Lethargeek
Lethargeek, Давно нет новостей. Будут новые фичи или уже не ждать? :)
drbars, будут, но не знаю когда :( экспериментирую помаленьку
если тебе для проекта нужно что-то конкретное - пиши в личку
и может быть, я сделаю быстрым хаком (не для релиза)
ждём-ждём :)Цитата:
Сообщение от Lethargeek
"Оптимизатор Атрибутов Летаргика" версия 1.0
От аналогичного продукта Screen Optimizer by g0blinish & Den Popov отличается более удобным (мне))) интерфейсом редактирования, а также алгоритмом автооптимизации (сокращает общее количество атрибутов, убирает неиспользуемые цвета). Алгоритм экспериментальный, но результаты неплохие. Заточен под мой Lethargeek Kompakt v1.1 (предпочтение горизонтальным полоскам одинаковых атрибутов), но и для других компрессоров полезен, так как старается привести одноатрибутные области к наиболее близкой к прямоугольной форме.
Сделано в mingw на C + SDL2 (dll включена), кодить диалог для файлов мне было влом, так что имена входного и выходного файлов задавайте как параметры командной строки.
Просьба сообщать об ошибках, особенно если в выходном скрине где-то вдруг изменятся видимые цвета (в самом редакторе этого не видно, цветной скрин там генерится только при старте).
Качать из блога: http://zx-pk.ru/entries/209-opal-las...-download.html
Было бы интересно увидеть сам алгоритм.
он еще меняться будет скорей всего, я пока что не вполне доволен его работойЦитата:
Сообщение от Шынни
А есть что то с расчетом именно на скорость распаковки а не на уровень сжатия?
за скоростью - это к побайтовым упаковщикам, их вроде бы хватало всегда)
люди - сделайте кто-нибудь уже кодек для видео на ZX - в принципе есть один от Витамина, с параметрами коэффициентом потерь и прочими - но нужен какой нибудь чтоб и быстрый и компактный и вообще это не дело - 2017год на дворе а видосики не покрутить - про ТС-конф тоже знаю, но там тупо поток несжатых картинок - это не то.
на Enterprise128 есть один. Им качество сжатия норм, мне zx7 больше нравится.Цитата:
Сообщение от Lethargeek
и при чём тут энтерпрайз вообще?..
а причем тут побайтовые упаковщики?Цитата:
Сообщение от Lethargeek
:v2_dizzy_facepalm: при том, что они работать могут быстрей почанковых (и других, у которых также "символ" с байтом не совпадает)Цитата:
Сообщение от Шынни
Несколько реквестов к упаковщику:
— возможность выбора для сжатия одной из 1/3 или 2/3 экрана на выбор с атрибутами и без.
— возможность упаковки графического ковра произвольного размера, с возможностью выборочной распаковки в линейный буфер (заданное смещение, длина).
drbars, я не знаю, когда время найду заниматься темой как полагается, мозг перенастроился на другое
могу пока склепать отдельную утилиту, обрезающую уже упакованную картинку снизу на любое кол-во тайловых строк
т.е. спрайты не ждать? :v2_down:Цитата:
Сообщение от Lethargeek