Сжатие и упаковка - обсуждение и сравнения

[BelaLugoci]

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

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

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

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

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

[Lethargeek]

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

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

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

да достаточно на код остаётся, да еще на теневой экранный буфер и на таблицы
например, в Nemesis the Warlock для 48k спека спрайты ~20k занимают (и это, вероятно, рекорд)
но обычно спрайты жрут намного меньше, а фоны набирают из небольшого числа тайлов и декораций

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

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

[jerri]

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

Вот именно в этом месте и можно использовать распаковку
именно так я и делал здесь

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

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

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

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

Я бы не стал называть это распаковкой - она должна быть максимально быстрой
посмотри Mortal Combat

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

[BelaLugoci]

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

[Bedazzle]

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

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

[drbars]

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

В Диззи-8 делал распаковку спрайта самого диззика так. В пределке 7-ой части тоже этот метод применил, значительно места появилось.

[Advertiser]

[Lethargeek]

В Диззи-8 делал распаковку спрайта самого диззика так. В пределке 7-ой части тоже этот метод применил, значительно места появилось.

ты не понял
у тебя каждый раз зеркалится в буфер нужная фаза
а я про то, что ВСЕ зеркалятся по месту хранения
(емнип то ли в paradise так, то ли в action force 2)

[Eugene85]

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

[Eugene85]

В компрессор OAPACK добавлен "ускоренный" режим почти без ущерба для сжатия. https://gitlab.com/eugene77/oapack

[tiboh]

В компрессор OAPACK добавлен "ускоренный" режим почти без ущерба для сжатия. https://gitlab.com/eugene77/oapack

А можно ли улучшить алгоритм сжатия для Laser Compact? Или хотя бы добавить дополнительные возможности паковки картикнки без атрибутов и по третям. Как это было в ZX версиях?
https://vtrd.in/release.php?r=82a719...7ef6d0e4817b7a