Сжатие данных

[svofski]

То есть вместо плеера и зажатой музыки в его формате, ты используешь многопоточный распаковщик который отправляет несжатую музыку пряма в AY?

Именно так. Это как проигрывание семплов, только семплы у нас тут не звуковые, а регистры, которые управляют AY, а частота обновления 50 Гц.

А если сравнивать какой нибудь плеер и музыку в его формате с твоим подходом. Где будет преимуществао в скорости и объеме данных?

Про объем -- размер данных в файле сопоставим, но для воспроизведения gigachad16 нужен буфер чуть меньше 4К (14 буферов распаковщика + 14 стеков).

Сравнение с единственным имеющимся у меня плеером pt2 для 8080 я привел в предыдущих сообщениях: gigachad16 5..20 строк, player-fml - 29..43. Если написать плеер честно, я думаю он будет все же заметно лучше, но пока никто этого не сделал.

[Advertiser]

[parallelno]

>gigachad16 5..20 строк, player-fml - 29..43
Строки это команды ассемблера?

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

В твоём "плеере" они выполняются каждое прерывание из последовательных 14, а два следующих прерывания не тратят процессорного времени. Плюс буфер 4к. Так?
В случае с плеером pt2. 2k плеер, и не нужен буфер. Объем сжатой музыки примерно одинаков. Так?

[svofski]

Строки это команды ассемблера?

Строки это строки экранной развертки. Так удобнее считать время, чем в тактах. Про прерывания и буфер правильно.

Про плеер нет. Имеющийся у нас плеер pt2 - 3067 байт и переменные его раскиданы как попало, в том числе он по-моему пишет куда-то еще в необозначенную область памяти (LA36E_ lxi sp, 08A32h etc - Достаточно взглянуть бегло на исходник). А тот плеер, про который говорит ivagor, его просто нет для 8080. Его надо сначала сделать.

[parallelno]

А сколько строк хороший плеер на z80 занимает про который говорил ivagor? Просто хочется узнать есть ли причина конвертить его на 8080.

[svofski]

А сколько строк хороший плеер на z80 занимает про который говорил ivagor? Просто хочется узнать есть ли причина конвертить его на 8080.

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

[ivagor]

Могу привести цифры для z80 с учетом векторовского торможения (смотрел в emu80). В среднем в районе 5000 тактов, максимумы (редкие) до 8000. Причина его конвертить - все же он будет несколько компактнее 14 поточного разжимальщика (думаю килобайта 3 максимум). Насколько медленнее - в худшем случае раза в полтора, если постараться - то быстрее. Но вряд ли кто-то будет стараться.

[svofski]

Но вряд ли кто-то будет стараться.

Я на самом деле, затаив дыхание, думал, вдруг ты напишешь -- "завтра-послезавтра выложу версию для 8080 на 10 строк"

С поточным плеером еще далеко не все сказано. Например, 256 -- удобный размер буфера и отличный компромисс, но бывают и окна поменьше. Например, все тот же EA Demosong при окне 64 сжимается до 3991 байт + 1204 байта буфера + стеки = 5195, а при буферах 256 на все вместе с данными нужно 6202, то есть можно килобайт сэкономить. Но это надо переписывать на менее удобные буфера.

[parallelno]

Я на самом деле, затаив дыхание, думал, вдруг ты напишешь -- "завтра-послезавтра выложу версию для 8080 на 10 строк"

С поточным плеером еще далеко не все сказано. Например, 256 -- удобный размер буфера и отличный компромисс, но бывают и окна поменьше. Например, все тот же EA Demosong при окне 64 сжимается до 3991 байт + 1204 байта буфера + стеки = 5195, а при буферах 256 на все вместе с данными нужно 6202, то есть можно килобайт сэкономить. Но это надо переписывать на менее удобные буфера.

А если буфера и стеки вынести на квазидиск в подэкранные области? Кстати сжатые стримы с окном 256 прилично сжимаются zx0 без окна.
То есть можно музыку держать дважды сжатой в игре. Потом распоковывать на квазидиск в подэкранные области и оттуда проигрывать в теории. По крайней мере у меня такой план. Или тут есть какие подводные камни?

[parallelno]

Напомните пожалуйста сколько одна строка таков?

[svofski]

parallelno, 59904 / 312 = 192.

Еще интересное отношение: частота процессора 3e6 / строчная частота 15625 = 192.