Сжатие и упаковка - обсуждение и сравнения [Архив] - Speccy

introspec

08.04.2014, 10:44

ZX7 (http://worldofspectrum.org/forums/showthread.php?t=42037) - это самый "модный" пакер на WoS. По сути, это переписанный Bitbuster, но с более качественным упаковщиком чем было в оригинале. Основные достоинства - скорость (думаю, это самый быстрый распаковщик в этих тестах) и наличие нескольких распаковщиков, самый компактный (и, понятно, самый медленный) из которых требует всего 69 байт.

ApPack (http://www.smspower.org/maxim/uploads/SMSSoftware/aplib12.zip) - это декомпрессор на основе старого досовского компрессора aPACK. Некто Maxim переписал исходный код распаковщика для z80 на Сеге, а затем Metalbrain сотоварищи написали серию распаковщиков (http://www.cpcwiki.eu/forum/programming/aplib-decruncher-10-faster-)/) оптимизированных по скорости распаковки и размеру распаковщика. Я думаю, что по скорости распаковки ApPack уступит только Bitbuster/ZX7. Поскольку это основной упаковщик в составе La Churrera, я подозреваю, что он гораздо шире используется, чем можно подумать на первый взгляд.

Малая распространённость Exomizer (http://hem.bredband.net/magli143/exo/) - это довольно странная ситуация, т.к. это самый эффективный компрессор в практически всех моих тестах, с довольно компактным распаковщиком (хотя ему и нужен буфер при распаковке). Распаковщик немного неторопливый, но там можно добавить где-то байт 5 для ускорения на 14% (см. комментарии Metalbrain в распаковщике).

Vitamin

08.04.2014, 12:29

затем Metalbrain сотоварищи написали серию распаковщиков
Судя по всему, все эти пакеры (начиная с MegaLZ) в погоне за качеством сжатия и последующей экономией на спичках напрочь потеряли какие-либо сигнатуры сжатых блоков. Значит детектить их можно исключительно по ограниченной разновидности пришпиленного распаковщика.
Для сравнения- все предыдущие компрессоры эту сигнатуру имели (семейство Hrust, MsPack) либо депакер был частью упакованного блока и сам являлся сигнатурой.

introspec

08.04.2014, 12:33

Судя по всему, все эти пакеры (начиная с MegaLZ) в погоне за качеством сжатия и последующей экономией на спичках напрочь потеряли какие-либо сигнатуры сжатых блоков. [...] Для сравнения- все предыдущие компрессоры эту сигнатуру имели
А, ок, теперь я понял вопрос. Ну, не знаю. С моей т.зр. нужно отличать архиваторы файлов от упаковщиков внутренних данных. Ни одна из перечисленных программ архиватором не являлась, насколько я знаю. Я не вижу смысла специально облегчать жизнь людям решившим раздербанить мою игру или мою демку.

Vitamin

08.04.2014, 12:41

Я не вижу смысла специально облегчать жизнь людям решившим раздербанить мою игру или мою демку.
Как говорится, "что один человек сделал, другой завсегда сломать может". В силу некоммерческости игр/демок и наличия богатого инструментария для раздербанивания (в отличие от старых времен), защита- пустая трата времени. А вот потерять что-то в таких условиях- очень легко. Имхо.

introspec

08.04.2014, 12:49

Как говорится, "что один человек сделал, другой завсегда сломать может". В силу некоммерческости игр/демок и наличия богатого инструментария для раздербанивания (в отличие от старых времен), защита- пустая трата времени. А вот потерять что-то в таких условиях- очень легко. Имхо.
Vitamin, этот спор тут немного неуместен (удали мой ответ если что). Но я не считаю компрессию защитой. Компрессия - это просто компрессия. Если программа распаковывает свои модули на лету - это не защита, а просто борьба с ограничениями памяти. Ни о какой потере информации речи быть не может, так как библиотеки для распаковки лежат тут же, рядом. Ну и вопрос: зачем мне тратить байты (которых и так явно мало) на идентификаторы сжатых блоков, если мне и так всё понятно и никаких возможностей для ошибки просто не существует?

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

alone

08.04.2014, 13:05

Всего в наборе 26 файлов объёмом 50344 байта. Вот результаты сжатия несколькими современными компрессорами:
Где можно взять эти файлы? Хотя бы интересует результат сжатия mRIP.

Vitamin

08.04.2014, 13:11

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

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

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

introspec

08.04.2014, 13:14

Где можно взять эти файлы? Хотя бы интересует результат сжатия mRIP.Прикладываю свой комплект файлов. Для справки, RAR 5.01 упаковал их до 29244 байт (-m5) или, если паковать в режиме solid архива, до 25056 (-s -m5).

Titus

08.04.2014, 13:48

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

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

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

introspec

08.04.2014, 13:51

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

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

Titus

08.04.2014, 13:53

Я думаю, что во всём нужна мера. Не в каждой ситуации скорость критична. Не в каждой ситуации быстрого распаковщика хватает, чтобы всё запихнуть.

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

Это надо прочувствовать то невероятное ощущение, когда начал загружать программу, и она за 2-3 секунды вся загрузилась и запустилась мгновенно.

Сравни, например, того же моего Murray Mouse и, и его же но пожатого другими пакерами или группами. Уже не говорю о монстрах типа Navy Seals.

Blade

08.04.2014, 13:55

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

Titus

08.04.2014, 13:58

Для игр упаковка вообще не нужна. С DivIDE неупакованная игра загрузится быстрее, чем упакованная.

А вот и не факт, если депакер распаковывает быстрее, чем идет перброс данных из вашего IDE-контроллера в память.

Blade

08.04.2014, 14:01

Не распакует быстрее. Чтение с IDE это INIR:INIR, или раскрытый цикл с INI.

alone

08.04.2014, 14:03

Titus

08.04.2014, 14:03

Не распакует быстрее. Чтение с IDE это INIR:INIR, или раскрытый цикл с INI.
Значит разница будет копеечная, ибо распаковщики есть со скоростью от LDIR до LDIR*2.

introspec

08.04.2014, 14:32

mRIP при настройках FF FA FF FA FA FA FA FF FF - 29133 (депакер 220 байт)
ZXRar в режиме Rar, Header off и при тех же настройках - 29103 (депакер 386 байт)

Похоже, они не годятся для таких маленьких файлов из-за того, что надо хранить деревья для каждого файла.
Если файлы склеить в один, то ZXRar даёт 26077 при тех же настройках (для сравнения, WinRar - 24955).
Вот поэтому я и писал о пользе, по прежнему, от сравнительно простых упаковщиков. Но у меня не получается сделать 24955 в rar. ОК, мою прошлую цифру я привёл по совсем старому rar (оказалось, что у меня валялась третья версия в путях). Поставил 5.01, получилось 26195 (solid архив, т.е. то же самое склеивание). Ты без учёта заголовков как-то посчитал, да?

alone

08.04.2014, 14:49

Без заголовков. Это число WinRar выводит сам в пункте "Информация". У меня v3.50.

introspec

08.04.2014, 15:42

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

---------- Post added at 12:26 ---------- Previous post was at 12:18 ----------

Для игр упаковка вообще не нужна. С DivIDE неупакованная игра загрузится быстрее, чем упакованная.
Вообще, конечно, вспоминая долгие годы в обнимку с магнитофоном и 48к, я бы предпочёл всё же чтобы игры упаковывали. Тем более что мне всегда казалось, что DivIDE принципиально не будет поддержана ни на одном отечественном клоне.

---------- Post added at 12:42 ---------- Previous post was at 12:26 ----------

Похоже, они не годятся для таких маленьких файлов из-за того, что надо хранить деревья для каждого файла.
Если файлы склеить в один, то ZXRar даёт 26077 при тех же настройках (для сравнения, WinRar - 24955).
У меня всего 48кб памяти на всё про всё. Склеить не получится никак :)

Titus

08.04.2014, 17:43

Соображения понятные, вот только речь идет не о сотнях байт, а о килобайтах, что хорошо видно по тестам в этом треде.

Даже если сэкономлен килобайт, в большинстве случаев это непринципиально.
Мгновенная распаковка - это круто)

alone

08.04.2014, 17:55

Titus

08.04.2014, 18:03

Hrumer

08.04.2014, 18:21

В New Wave 48K это имело смысл, т.к. в каждой подгрузке по два эффекта, из которых один работает, другой хранится в упакованном виде. Ни один пакер, кроме Exomizer'а, не справлялся с задачей.

Есть предложение, при возможности аттачить тестовые
файлы. Я вот, кстати, не понял про архив rar от introspecа.

Внутри написано, что:

Solid archive testfiles.rar

Это что, при коротких файлах он принудительно солид делает?

Upd: а, всё, дошло.

GM BIT

09.04.2014, 05:07

Еще:
сравнение размеров и скорости распаковки
http://psndcj.blogspot.ru/2010/09/blog-post.html

introspec

09.04.2014, 11:41

Еще:
сравнение размеров и скорости распаковки
http://psndcj.blogspot.ru/2010/09/blog-post.htmlВ тестах psndcj, наверняка, использовался "старый" упаковщик Hrust, поэтому он и идёт ноздря-в-ноздрю с MegaLZ, даже отстаёт по коэффициенту сжатия немного. Думаю, если использовать новый упаковщик LVD (он называется mhmt), хруст должен выйти победителем теста psndcj по сжатию.

Shadow Maker

10.04.2014, 09:37

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

Hrumer

10.04.2014, 09:54

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

Можно. Но, скорее всего, скорректировав заголовок. И, возможно, у LVD файл сжимается с последними 6 байтами, а у хруста1 они незапакованными хранятся. Надо у LVD спрашивать.

upd: а не надо спрашивать, и так видно, что без заголовка, и файл жмется весь, до последнего байта.

11.04.2014, 19:10

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

Если это рипы музона и плейеров из разных игрушек, то можно проверить, что будет при сжатии в 2 или 3 архива (отдельно код, музло, графика). Есть шансы улучшить результат.

Прикладываю свой комплект файлов. Для справки, RAR 5.01 упаковал их до 29244 байт (-m5) или, если паковать в режиме solid архива, до 25056 (-s -m5).

23055 солид (+537 на хедерный хлам), и на пк компрессоров получше наверное вагон и маленькая тележка -- сжал чем пользуюсь. Но в данном случае жать универсальным компрессором -- не лучший вариант. "Вполуручную" скорее всего получится сделать круче. И, возможно, намного (если хорошо знать исх. материал).

У меня всего 48кб памяти на всё про всё. Склеить не получится никак

Так вроде нет никакой проблемы со склейкой воедино под 48к, почему не получится? Другое дело, что это необязательно лучший вариант -- сжав код и музон (и графику) по отдельности, есть вероятность выиграть в суммарном размере.

introspec

11.04.2014, 19:16

Интроспек, а в архиве ваши наработки или чьи-то?

Если это рипы музона и плейеров из разных игрушек, то можно проверить, что будет при сжатии в 2 или 3 архива (отдельно код, музло, графика). Есть шансы улучшить результат.

Но в данном случае жать универсальным компрессором -- не лучший вариант. "Вполуручную" скорее всего получится сделать круче. И, возможно, намного (если хорошо знать исх. материал).

Так вроде нет никакой проблемы со склейкой воедино под 48к, почему не получится?
Это мои рипы чужой биперной музыки. Разбивание на архивы и перегруппировка не слишком актуальны, т.к. это потребует подробного анализа, на который у меня нет времени. Разумеется, компрессор общего назначения жмёт хуже чем специализированный. Но тест сжатия чем-то вроде RAR, отлаженного для широкого применения, даёт неплохое представление о неэффективности выбранного представления на спектруме.

Склейка же не пройдёт потому, что на 48к машине нет 50к памяти :)

Shadow Maker

11.04.2014, 21:10

AM, Во-первых, табличка наглядная.
Во-вторых, я мало себе представляю человека, который такой разносторонне одаренный, что будет специализированно для своих данных изобретать компрессор.
В-третьих, хватит уже беспредметно. Есть какой-то конкретный компрессор для спектрума, который пакует данные introspec'a лучше и распаковывает быстрее? Прекрасно, показываем, делимся. А то "у меня РАР для ПЦ зажал круче" это ни о чем.

introspec, спокойнее, дышим ровнее. Никто никому ничего не должен. Не стоит так бурно реагировать.

Titus

11.04.2014, 21:40

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

В-третьих, хватит уже беспредметно. Есть какой-то конкретный компрессор для спектрума, который пакует данные introspec'a лучше и распаковывает быстрее? Прекрасно, показываем, делимся. А то "у меня РАР для ПЦ зажал круче" это ни о чем.

Я делал не раз компрессоры именно для своих данных)

Быстрее всех скорее всего распаковывает любые данные мой Pro Turbo Cruncher (http://zx.pk.ru/showpost.php?p=627584&postcount=21).

Shadow Maker

11.04.2014, 21:49

Андрей, тебе это интересно было, так ведь? Именно написать упаковщик, чтобы быстро распаковывал и с хорошим сжатием. Однако таких как ты - единицы (а жаль!).

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

Такие дела :)

11.04.2014, 21:58

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

---------- Post added at 21:58 ---------- Previous post was at 21:53 ----------

Андрей, тебе это интересно было, так ведь? Именно написать упаковщик, чтобы быстро распаковывал и с хорошим сжатием. Однако таких как ты - единицы (а жаль!).

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

Такие дела :)

В итоге это к теме "шашечки или ехать". Если надо ехать -- давайте конкретные данные, посмотрим что можно с ними сделать. Если шашечки (у кого длиннее компрессор) или флейм -- извините.

Shadow Maker

11.04.2014, 22:02

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

introspec

11.04.2014, 22:10

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

Как может помочь таблица вроде той, что я тут привёл?

Пример 1: месяц назад я писал 1к интру, для которой мне нужно было сжать 3к графики. Выигрыш в несколько процентов может быть важным на больших наборах данных, но, в данном случае, разница между лучшим и худшим компрессором не превышала 50 байт (от 538 до 587 байт). Поэтому оказалось, что для решения данной задачи, компрессор zx7 оказался оптимальным инструментом, благодаря намного более компактному распаковщику.

Пример 2: данные, которые я выложил в этом треде - это треки для моей слегка протухшей биперной демы. Когда я выбирал оптимальный компрессор для этой демы в прошлом году, mhmt ещё не существовал, и мои знания о современных компрессорах были ограничены. В моих прошлогодних тестах выиграл MegaLZ. Дема протухла из-за недостатка времени и очень жёстких проблем с памятью. В этом году я повторил свои тесты с более широким наборов компрессоров и вижу, что заменив MegaLZ на Hrust, и используя mhmt, я получаю около килобайта дополнительной памяти. Что интересно, использование Exomizer в этом случае оказывается неоправданным, т.к. выигрыш в объёме сжатых данных оказывается нивелирован требованием дополнительной памяти для буфера распаковки.

12.04.2014, 09:01

introspec

12.04.2014, 11:54

Вы почему-то упорно пытаетесь ловить десятки байтов подбором компрессора, в то время как нередко можно получить намного больший выигрыш -- без сжатия и без месяца на сбор соотв. статистики и эксперименты.
"Есть какой-то конкретный компрессор для спектрума, который пакует данные introspec'a лучше и распаковывает быстрее? Прекрасно, показываем, делимся."

Eugene85

08.05.2020, 18:40

В академических целях написан оптимальный компрессор для формата aPack/aPLib. Оставлю здесь, вдруг кому пригодится :)
https://gitlab.com/eugene77/oapack

UPD 2025: добавлен "ускоренный" режим (с минимальным ущербом для сжатия).

ivagor

08.05.2020, 19:44

Сравнил с apc12spke на 20 файлах - oapack нигде не проиграл, иногда выиграл по несколько байт, один раз - 115 байт. Но удивительно медленный.

ivagor

09.05.2020, 08:21

Пропустил, оказывается уже есть следующий быстрый компрессор для этого формата - apultra (https://github.com/emmanuel-marty/apultra). У него нет проигрыша в 100 байт, максимум 8 байт на моем наборе тестовых файлов и сжимает быстро. Но если для какого-то применения несколько байт критичны, то подойдет oapack.

NEO SPECTRUMAN

26.12.2020, 23:46

а где выкопать последний zx7 с собранымм пакером?

Shadow Maker

26.12.2020, 23:57

Последний это какой? Этот? https://github.com/antoniovillena/zx7b Если не этот, то оригинальный тут вот есть https://vtrd.in/pcutilz.php

NEO SPECTRUMAN

28.12.2020, 22:30

Этот? https://github.com/antoniovillena/zx7b
этот оказался переделанный для работы задом наперед
от этого и название ZX7 Backwards

в моем случае он даже сожрал на 33 байта больше чем старый zx7 со второй ссылки
на других данных подсунутых для теста разница 1 байт в пользу старого zx7

Shadow Maker

28.12.2020, 23:18

этот оказался переделанный для работы задом наперед
от этого и название ZX7 Backwards

в моем случае он даже сожрал на 33 байта больше чем старый zx7 со второй ссылки
на других данных подсунутых для теста разница 1 байт в пользу старого zx7
Ну упакованные назад можно в то же место распаковывать, это часто важно. Упакованные вперед часто себя перетирают.

NEO SPECTRUMAN

28.12.2020, 23:21

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

но мне для многократных распаковок :v2_dizzy_roll:
и с людскими "началами" проще работать чем с концами :)

ivagor

29.12.2020, 06:21

В репозитории zx7b много чего, и если говорить про околоzx7, то самый интересный там saukav.exe. Это обобщенный вариант zx7 (и zx7mini) с опциями позволяющими сжимать вперед и назад, с разными ограничениями для смещения и двумя вариантами гамма-функции. При правильном подборе опций он сжимает лучше zx7

NEO SPECTRUMAN

29.12.2020, 08:23

saukav.
негодится по причине

the decompression routine is generated by the compressor.

ivagor

29.12.2020, 09:02

негодится по причине
the decompression routine is generated by the compressor.
Это не обязательно, можно использовать свои распаковщики, например я делал для 8080, для которого автор конечно распаковщиков не предусмотрел.

NEO SPECTRUMAN

29.12.2020, 09:31

а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?

ivagor

29.12.2020, 10:25

Все lzподобные лезут в уже распакованные данные, но как раз saukav при использовании минимальной битности смещения (или zx7mini, но лучше saukav) позволяет ограничиться кольцевым буфером в 256 (для скорости и удобства) байт. Для примера можно сделать распаковщик картинок, который будет выводить в произвольном (нелинейном) порядке на экран, главное чтобы в кольцевом буфере была копия последних распакованных данных.

jerri

29.12.2020, 14:40

а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?

RLE. но жмут они так себе.

NEO SPECTRUMAN

29.12.2020, 14:44

RLE. но жмут они так себе.
есть жо еще хафманы

но я спрашиваю за готовое решение

а так смотря что жать
когда данные типа 1,1,1,1,1,2,2,2,2,2.3,3,3,3,3
rle подобное пакует на ура
я вообще описываю\сжимаю как количество повторений до инкримента :)

jerri

29.12.2020, 15:13

есть жо еще хафманы

но я спрашиваю за готовое решение

а так смотря что жать
когда данные типа 1,1,1,1,1,2,2,2,2,2.3,3,3,3,3
rle подобное пакует на ура
я вообще описываю\сжимаю как количество повторений до инкримента :)

а что хаффманы? ты хочешь еще доп буфер под данные использовать?

NEO SPECTRUMAN

29.12.2020, 16:24

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

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

в принципе вариант с кольцевым буфером тоже подходит

jerri

29.12.2020, 16:47

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

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

в принципе вариант с кольцевым буфером тоже подходит

А дерево оно в воздухе растет да? :)
оно как раз и занимает вот тот самый буфер.

NEO SPECTRUMAN

27.01.2021, 21:05

Ну упакованные назад можно в то же место распаковывать, это часто важно. Упакованные вперед часто себя перетирают.
но тут успешно не указывают на сколько можно делать этот overlap

в zx0 аффтар даже наглядно показывает "дельту" какой зазор должен оставаться и пишет оно при упаковке
ну и умя там выходит 2 байта

compressed data |------------------|
decompressed data |---------------------------------|
<---> << start
delta

https://github.com/einar-saukas/ZX0

среди всего хлама есть пакеры гарантировано с дельтой = 0 ?

тк варианты с !=0 и переменного размера только способствуют дополнительной головной боли в моем случае...

Eugene85

28.01.2021, 00:26

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

Hrust 1 & 2 обеспечивают дельта=0 для подавляющего большинства файлов, но декомпрессор использует буфер 6 байт на стеке.

polikarpov76

30.11.2021, 08:23

ivagor

30.11.2021, 09:09

как банальный RLE может быть эффективнее методов сжатия по Хаффману?
У него не "банальный RLE", а еще и ДИКМ и пусть не Хаффман, но экономное кодирование. И "эффективнее" в случае QOI значит в основном "быстрее", сжимает PNG в среднем лучше.

Sandro

30.11.2021, 13:07

Любопытная статья 'Программист, не имеющий представления о сжатии данных, создал суперзамену формату PNG (https://www.cnews.ru/news/top/2021-11-29_programmist_bez_predstavleniya)'.
Вопрос а как банальный RLE может быть эффективнее методов сжатия по Хаффману?

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

Во-первых, алгоритмы подобного рода изобретает каждый второй. Сам грешен. На естественных изображениях подойти близко к PNG действительно легко -- по той простой причине, что они вообще плохо сжимаются алгоритмами без потерь.

Во-вторых, автор алгоритма ошибочно считает, что поскольку PNG -- без потерь, то он всегда одинаковый. И взял для сравнения мини-упаковщик из коллекции алгоритмов STB. Он фиговый. Сравнивать надо с монстрами типа PNGCrush или OptiPNG. Вот им-то он и сольёт.

В-третьих, PNG таки реально дендрофекальная конструкция сляпанная на коленке для замены внезапно запатентованному gif. Отыграть 10%-15% на естественных изображениях у PNG можно. Особенно, если они большие. Но не настолько простым способом.

lexarr

19.03.2022, 22:29

Исходник распаковщика для i8080:

nrv2d-i80.7z (https://zx-pk.ru/attachment.php?attachmentid=81890)

Это алгоритм NRV2d из библиотеки UCL (такие упаковщики уже были). Размер - около 200 байт. Только оригинальный поток, запакованный с помощью утилиты uclpack, не подходит. Но написано как переделать: в функции ucl_nrv_99_compress поменять одно значение. Правильный упаковщик n2dpack прилагается. Пример использования (https://zx-pk.ru/attachment.php?attachmentid=74083) (для ПК «Специалист»): исходный размер – 17 кБ, сжатый – 5 кБ.
Может кому пригодится.

Eugene85

19.03.2022, 23:38

Появились компрессоры RIP и mRIP на PC. Будет что пообсуждать и посравнивать :)

https://gitlab.com/eugene77/rip
https://gitlab.com/eugene77/mrip

UPD: Добавил краткое описание формата (https://gitlab.com/eugene77/rip/-/blob/master/format_description.txt).

Eugene85

25.03.2022, 20:55

а нету готовых упаковщиков с алгоритмами
которые не лезут в уже распакованные данные?

Случайно вспомнил про упаковщик dict от Булата Зиганшина, автора архиватора FreeArc.
Декомпрессор не имеет состояния и простой донельзя, будет очень быстрым даже на спектруме.
Реализация есть только на PC, правда. Отыскать в сети его уже нереально, поэтому прилагаю прям здесь; в архиве и исходник, и описание формата, и бинарник.

77179

drbars

26.03.2022, 10:21

Случайно вспомнил про упаковщик dict от Булата Зиганшина, автора архиватора FreeArc.
Декомпрессор не имеет состояния и простой донельзя, будет очень быстрым даже на спектруме.
Реализация есть только на PC, правда. Отыскать в сети его уже нереально, поэтому прилагаю прям здесь; в архиве и исходник, и описание формата, и бинарник.

Есть некоторые сомнения что z80 потянет ppmd. У меня есть несколько таких компрессоров, результаты очень хорошие.

Eugene85

26.03.2022, 19:59

drbars, вы что-то попутали, ppmd тут совершенно ни при чём.

drbars

27.03.2022, 10:20

drbars, вы что-то попутали, ppmd тут совершенно ни при чём.
Точно, там оптимизация для улучшения сжатия ppm алгоритмом.

Eugene85

27.03.2022, 15:56

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

drbars

28.03.2022, 17:24

Для z80 по идее ещё можно использовать kzip (http://advsys.net/ken/utils.htm). Он даёт очень хорошие результаты, чуть лучше rip/mrip даже.
Распаковать можно утилитой unzip для trdos. Автономного депакера не встречал.

ivagor

28.03.2022, 18:09

ещё можно использовать kzip. Он даёт очень хорошие результаты, чуть лучше rip
Если сравнивать с упаковщиком Eugene85, то нет, по крайней мере пока мне не удалось найти файлов, на которых kzip лучше.

Eugene85

28.03.2022, 19:45

ivagor, подозреваю, что ты не учёл структуры архива zip, это примерно 110..120 байт.

drbars, действительно, выжимает все соки из формата deflate. И всё же rip'у чаще проигрывает, чем выигрывает; сравнивал на своём корпусе, причём за вычетом структур zip. И главное: распаковщик, говорят (https://zx-pk.ru/threads/29679-szhatie-dannykh.html?p=1133970&viewfull=1#post1133970), занимает под 2 КБ :\

Sandro

28.03.2022, 20:13

ZIP/Deflate -- это боль. Я несколько раз порывался написать его распаковщик для БК, но каждый раз, как перечитывал документацию -- всё желание пропадало. Он безобразно тяжёлый. И алгоритмически, и по размеру кода, и по необходимой памяти.
А сжатие так себе.

ivagor

28.03.2022, 20:18

подозреваю, что ты не учёл структуры архива zip, это примерно 110..120 байт
Заголовок я учитывал, но тогда попробовал слишком мало файлов. Сейчас попробовал 21 файл, kzip выиграл в 4 из 21, но очень незначительно, в целом rip уверенно победил (и это даже без учета сложности распаковщика zip).

Dart Alver

28.03.2022, 23:12

Любопытно а есть упаковщики/распаковщики позволяющие извлекать выборочную последовательность из общего упакованного кода ?

ivagor

29.03.2022, 06:22

есть упаковщики/распаковщики позволяющие извлекать выборочную последовательность из общего упакованного кода ?
Если в упаковщиках с LZ смещение для копирования из распакованных данных более-менее ограниченное (до единиц килобайт тому назад), то можно сделать распаковщик с кольцевым буфером, позволяющий распаковывать хоть побайтно. Сам делал такой вариант для saukav.exe (https://github.com/antoniovillena/zx7b) (там как раз можно выбирать размер буфера при упаковке). Можно сделать такой распаковщик для MegaLZ и вроде даже делали.

drbars

29.03.2022, 10:59

Любопытно а есть упаковщики/распаковщики позволяющие извлекать выборочную последовательность из общего упакованного кода ?
Huffman, Arithmetic coding подойдёт думаю.

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

Кстати, есть ли реализация Arithmetic coding для z80 ? На текстах этот метод даёт результат лучше Huffman'а.

ivagor

29.03.2022, 11:08

Кстати, есть ли реализация Arithmetic coding для z80 ?
Насчет кодирования не знаю, а распаковщик с LZMA есть - shrinkler (https://www.cpcwiki.eu/forum/programming/shrinkler-z80-decrunch-routine/)

drbars

29.03.2022, 11:43

Насчет кодирования не знаю, а распаковщик с LZMA есть - shrinkler (https://www.cpcwiki.eu/forum/programming/shrinkler-z80-decrunch-routine/)
Это другое. Арифметическое кодирование - это метод сжатия. Вопрос был если ли для этого метода реализация для z80.

ivagor

29.03.2022, 12:03

Арифметическое кодирование - это метод сжатия
Спасибо, а то я не знал.

Sandro

29.03.2022, 14:10

Кстати, есть ли реализация Arithmetic coding для z80 ? На текстах этот метод даёт результат лучше Huffman'а.

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

drbars

30.03.2022, 11:18

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

Sandro

30.03.2022, 11:41

Я наилучшие результаты с текстами получал на ppm методах. Но спек такое распаковать не сможет.

PPM -- это по сути алгоритм с неявным словарём; точнее, в нём словарь конструируется по мере обработки потока. В теории, при этом происходит экономия на передаче отдельного словаря. На практике, во всех алгоритмах с неявным словарём, а это не только PPM, но и всё семейство LZ*, например, происходит замусоривание словаря записями, которые никогда не будут использованы. Что уменьшает степень сжатия.

На самом деле, PPM с небольшой глубиной контекста (предыстории) на спеке сделать можно. Но смысл этого неясен.

BelaLugoci

30.03.2022, 13:05

На текстах этот метод даёт результат лучше Huffman'а
AК априори лучше Хаффмана, оба метода энтропийные, но у Хаффмана разрядность побитовая, а в АК дробная. Поэтому АК не может быть хуже Хаффмана.
Сейчас интересен rANS, но мало материалов и даже читая материалы от разработчика не могу с ним разобраться совсем (впрочем я и с АК плохо разбираюсь, только понимаю теорию).
Сейчас на ПК для себя пользуюсь zpaq64 если есть время для сжатия, если нет, то 7zip PPMd FAST.
Хаффманом обычно дожимают, так как у него задача такая - снижение энтропии. Например если взять файл 1024 байт заполненный нулями, то Хаффман сожмёт его максимум в 8 раз + служебка всякая, а банальный LZ сделает байт 30, что даст сжатие в 33 раза. как то так.

BelaLugoci

05.04.2022, 10:25

Вопрос, кто-то изучал момент сжатия битовых изображений - спрайтов, с быстрым доступом "на лету". Пока ничего лучшего чем фиксированная таблица для Хаффмана посчитанная по факту с разбиением данных по блокам - ничего не придумывается., но там 256 байт на таблицу сразу отдаём и в среднем по 4 бита на "хвост" спрайта для выравнивания по блокам. Зато при распаковке буфер всего в пару-тройку байт нужен и довольно быстрые операции со сдвигами.

Lethargeek

05.04.2022, 11:26

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

BelaLugoci

05.04.2022, 12:57

прямо на экран из потока сжатого?
да, на этапе vsync например

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

по размеру - ну тут от контента зависит, хаффман же энтропийный кодер, если много будет повторяющихся данных то и сожмёт хорошо, даже 1:2 это много.

drbars

05.04.2022, 17:14

Вспомнился ещё один интересный упаковщик из прошлого — ACB (associative coding algorithm). Помню давал очень приличное сжатие.

BelaLugoci

06.04.2022, 05:45

ACB (associative coding algorithm). Помню давал очень приличное сжатие
эх, этот алгоритм везде как мем уже. в любом случае он безумно медленный даже на пентиумах, что уж говорить про 6502/z80

Lethargeek

06.04.2022, 10:32

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

а вот однократная распаковка графики для нового уровня (и даже каждого нового экрана) вполне оправданна и на практике применяется

BelaLugoci

06.04.2022, 12:15

(и даже каждого нового экрана)
так, не понял здесь. экран меняется 50 раз в секунду (я про PAL ATARI), то есть отрисовывая анимированные спрайты для смены экрана, я могу данные распаковывать? чем это отличается от ранее мной описанного? это же и есть на лету. Вот появился новый монстр впервые, я его распаковываю, показываю, он улетает, удаляю. Это же "на лету" - для каждого нового экрана.

Lethargeek

06.04.2022, 14:33

так, не понял здесь. экран меняется 50 раз в секунду (я про PAL
:v2_dizzy_facepalm: снова на отдельные слова реагируем, даже не пытаясь вникнуть в контекст?

а вот однократная распаковка графики для нового уровня (и даже каждого нового экрана)
то есть очевидно речь про экран ИГРЫ (я бы написал "комната", но не всякие экраны можно комнатами назвать)
а НЕ про КАДР, тем более, что крайне редко в спековских играх частота кадров ИГРЫ достигает частоты PAL

BelaLugoci

06.04.2022, 16:47

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

тем более, что крайне редко в спековских играх частота кадров ИГРЫ достигает частоты PAL
если вы за vsync не успеваете обработать данные то что берётся за базис синхронизации? как будет музыка проигрываться без дефектов?

Lethargeek

06.04.2022, 16:55

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

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

то что берётся за базис синхронизации?
а явной синхронизации вообще в игрушках может не быть :p

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

BelaLugoci

07.04.2022, 05:41

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

значит, продолжаем обрабатывать в новом кадре
то есть поэтому в ZX всё любит мерцать, исчезать и появляться в любой момент? там же почти 4 мгц по сравнению с 6502 это в 2 раза больше, а на 6502 таких проблем я не наблюдаю. Да и масса источников пишет именно о работе кода игры в момент vsync. Ладно если сознательно из 50 гц вы делаете 25, но если у вас может быть сначала 50 потом 20 потом 5 потом опять 50 - как таким пользоваться? если на ZX это норма, то это прям жуть.
хотя мне кажется я сам смогу ответить на этот вопрос (ну или предположу) - в ZX нет ANTIC чипа, поэтому флип-скрин и скроллы делаются программно?

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

Lethargeek

07.04.2022, 11:38

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

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

Да и масса источников пишет именно о работе кода игры в момент vsync
очередная совершеннейшая бессмыслица - что значит "работа кода игры в МОМЕНТ vsync"??
какова длина "момента" вообще? а во все прочие "моменты" чем занят комп? :D

Ладно если сознательно из 50 гц вы делаете 25, но если у вас может быть сначала 50 потом 20 потом 5 потом опять 50 - как таким пользоваться?
так не пользуйтесь, дизайн уровней может быть таким, что разброс получится небольшим

в ZX нет ANTIC чипа, поэтому флип-скрин и скроллы делаются программно?
в zx-графике ВСЁ делается программно

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

Bedazzle

07.04.2022, 20:21

в zx-графике ВСЁ делается программно

/придирается/ flash - аппаратный

BelaLugoci

08.04.2022, 06:02

очередная совершеннейшая бессмыслица - что значит "работа кода игры в МОМЕНТ vsync"??
какова длина "момента" вообще? а во все прочие "моменты" чем занят комп?
пока идёт построчное формирование изображения, то, если вы следите за каждой строкой, вы можете менять содержимое видео памяти только для тех строк, которые еще не нарисованы. Если вы рисуете что-то в памяти, из которой луч ничего не рисует, то на следующем кадре, если вы ту область не обновите, изображение появится.
если вы не следите за vsync, и рисуете (заполняете vram) по принципу как хочу и когда хочу, то у вас неизбежны проблемы - мерцание объектов, отсутствующие объекты, обрезанные объекты (визуально это выглядит как мерцание например части спрайта).
Например для Atari есть аппаратное определение столкновений спрайтов - будете делать абы-как, оно не будет работать.

запустил одну музыку в меню, выключил когда игра начинается
запустил другую в начале уровня, выключил после окончания уровня
где проблемы? графику не надо синхронизировать
это ни о чем не говорит. всё зависит от кода программы, рассинхронизация носит накопительный характер и разницу в 50 мс например на короткой и не тяжёлой программе вы никак не заметите.
если же вы говорите о музыке на фоне, когда нет нужды стыковать кадры изображения и звука, то действительно нет никакой разницы, даже рассинхрон на 20 секунд никто не заметит, но я-то не об этом.

выдержка из сети:

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

так же дополнительная информация есть здесь (https://www.atariarchives.org/agagd/chapter6.php), в том числе ответ про время возврата луча.

в zx-графике ВСЁ делается программно
как правильно заметили - не всё. но в целом я понял в чём причина артефактов.

Lethargeek

08.04.2022, 09:13

пока идёт построчное формирование изображения, то, если вы следите за каждой строкой, вы можете менять содержимое видео памяти только для тех строк, которые еще не нарисованы. Если вы рисуете что-то в памяти, из которой луч ничего не рисует, то на следующем кадре, если вы ту область не обновите, изображение появится.
это всё известная азбука но при чём тут "работа кода В МОМЕНТ"? за "момент" выполнится несколько команд только :D

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

Например для Atari есть аппаратное определение столкновений спрайтов - будете делать абы-как, оно не будет работать.
к спеку отношения не имеет

это ни о чем не говорит. всё зависит от кода программы, рассинхронизация носит накопительный характер и разницу в 50 мс например на короткой и не тяжёлой программе вы никак не заметите.
если же вы говорите о музыке на фоне, когда нет нужды стыковать кадры изображения и звука, то действительно нет никакой разницы, даже рассинхрон на 20 секунд никто не заметит, но я-то не об этом.

выдержка из сети:

В видеоиграх вертикальные импульсы так же используются для синхронизации. Большинство графических операций на игровых консолях, включая и 16-битную эру, могло быть выполнено только в течение кадрового гасящего импульса (который программисты часто называли VBLANK), требуя от программ выполнять всю обработку графики исключительно за это время.
а при чём тут ЗВУК? полностью "проблема" высосана из пальца
как сказал, AY музыка и звуковые эффекты отдельный процесс
для эффекта просто взводится флажок когда нужно

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

jerri

08.04.2022, 10:02

BelaLugoci, вы ушли немного в другую степь

Обработка игрового цикла - это одно

подготовка данных и утилизация ненужных данных происходят на этапе подготовки, в процессе игрового цикла - очень редко.

[инициация игрового экрана]
|
[обработка игровых событий внутри экрана] <-[до завершения]
|
[завершение игрового экрана] -> [принятие решения]

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

BelaLugoci

08.04.2022, 12:39

распаковка требуется только в первом блоке
в процессе игровых событий не требуется распаковка данных.
[инициация игрового экрана]
это неизменяемые данные совсем-совсем?

если данные для текущего уровня не позволяют их держать в готовом распакованном виде?
условный bitmap будет занимать в ОЗУ столько, сколько он весит и если буфер vram у вас например 8 Кб, и все данные у вас распакованы, то у вас уже 16 Кб занято (утрирую, там может быть как 8+1, 8+8 так и 8+28), то есть на код останется мало (помним про Бейсик, DOS и прочее в ОЗУ).

я подумал о концепции когда используется какое-то быстрое и простое кодирование, пусть для примера это будет RLE, которое сократит использование памяти например на 20%, а это уже 1-1,5 Кб к примеру.
Для вывода формируется буфер, например 2х16 байт, куда раскодируются спрайты перед копированием в vram, возможно это можно делать только регистрами, тут уж я не знаю, зависит от способа кодирования и раскодирования.

просто на современных платформах это в порядке вещей, но никто не спорит что сегодня это ЦПУ на гигагерцы и возможно для 6502/z80 это проблема. Думаю нужно проверять опытным путём. Просто в одной игре это параллакс, несколько слоев и наложений, а в другой всё проще, возможно там и можно пользоваться распаковкой на лету.

Lethargeek

08.04.2022, 14:07

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

условный bitmap будет занимать в ОЗУ столько, сколько он весит и если буфер vram у вас например 8 Кб, и все данные у вас распакованы, то у вас уже 16 Кб занято (утрирую, там может быть как 8+1, 8+8 так и 8+28), то есть на код останется мало (помним про Бейсик, DOS и прочее в ОЗУ).
да достаточно на код остаётся, да еще на теневой экранный буфер и на таблицы
например, в Nemesis the Warlock для 48k спека спрайты ~20k занимают (и это, вероятно, рекорд)
но обычно спрайты жрут намного меньше, а фоны набирают из небольшого числа тайлов и декораций

я подумал о концепции когда используется какое-то быстрое и простое кодирование, пусть для примера это будет RLE, которое сократит использование памяти например на 20%,
это вряд ли, спрайты в играх довольно плотные, байт - узкая полоска из 8 пикселей, очень мало будет пустых подряд, как бы даже не распух размер с RLE

jerri

08.04.2022, 14:52

[инициация игрового экрана]
это неизменяемые данные совсем-совсем?

Вот именно в этом месте и можно использовать распаковку
именно так я и делал здесь (https://spectrumcomputing.co.uk/entry/30109/ZX-Spectrum/lAbbaye_des_Morts)

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

если данные для текущего уровня не позволяют их держать в готовом распакованном виде?
условный bitmap будет занимать в ОЗУ столько, сколько он весит и если буфер vram у вас например 8 Кб, и все данные у вас распакованы, то у вас уже 16 Кб занято (утрирую, там может быть как 8+1, 8+8 так и 8+28), то есть на код останется мало (помним про Бейсик, DOS и прочее в ОЗУ).

я подумал о концепции когда используется какое-то быстрое и простое кодирование, пусть для примера это будет RLE, которое сократит использование памяти например на 20%, а это уже 1-1,5 Кб к примеру.
Для вывода формируется буфер, например 2х16 байт, куда раскодируются спрайты перед копированием в vram, возможно это можно делать только регистрами, тут уж я не знаю, зависит от способа кодирования и раскодирования.

просто на современных платформах это в порядке вещей, но никто не спорит что сегодня это ЦПУ на гигагерцы и возможно для 6502/z80 это проблема. Думаю нужно проверять опытным путём. Просто в одной игре это параллакс, несколько слоев и наложений, а в другой всё проще, возможно там и можно пользоваться распаковкой на лету.

Я бы не стал называть это распаковкой - она должна быть максимально быстрой
посмотри Mortal Combat (https://spectrumcomputing.co.uk/entry/12966/ZX-Spectrum/Mortal_Kombat)

там к этому делу подошли основательно.

BelaLugoci

08.04.2022, 16:40

спасибо всем за дискуссию, будет что показать - вернусь в тему.

Bedazzle

09.04.2022, 21:43

я подумал о концепции когда используется какое-то быстрое и простое кодирование, пусть для примера это будет RLE

Для эксперимента делал в Heavy on the magick упаковку спрайтов врагов при помощи zx7, и в момент, когда монстр появляется в комнате, происходила распаковка спрайтов + маски в небольшой буфер, откуда дальше идёт отрисовка штатным методом. Небольшая задержка не заметна, - и само количество распаковываемых байт незначительно, и сам геймплей позволяет (например, при переходе между комнатами перерисовка экрана не мгновенная). Решение с буфером потому что движок игры в реальном времени зеркалит спрайт туда-сюда, оживляя монстра, и нет выигрыша держать упакованый оригинал и зеркальную копию.