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

[BelaLugoci]

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

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

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

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

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

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

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

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

как правильно заметили - не всё. но в целом я понял в чём причина артефактов.

[Advertiser]

[Lethargeek]

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

это всё известная азбука но при чём тут "работа кода В МОМЕНТ"? за "момент" выполнится несколько команд только

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

повторяю, это необязательно - смотреть Exolon и учить матчасть!

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

к спеку отношения не имеет

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

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

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

а при чём тут ЗВУК? полностью "проблема" высосана из пальца
как сказал, AY музыка и звуковые эффекты отдельный процесс
для эффекта просто взводится флажок когда нужно

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

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

[jerri]

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

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

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


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


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

[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

[drbars]

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

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

[Lethargeek]

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

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

[jerri]

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

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

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

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

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

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

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

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

[Bedazzle]

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

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