Программирование

[svofski]

Выколупывание все-таки не самое мое любимое занятие, но вот плеер из "Полета навигатора".

Компактненький, 1400 байт примерно. По времени 37-50 строк. Осталось разобраться, что за формат файла он играет.

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

Ага, методом перебора нашел, что это формат STC. Попробовал другой музон в этом формате, работает. Не самый популярный формат. Не знаю, как обстоят дела с конвертацией pt3 -> stc, но подозреваю, что никак.

Upd: ссылка на оригинальный музон DOCZak1 by DOC'NEONSOFT. Интересно, что в polet4k имя автора затерто.

[parallelno]

Спасибо за инфу! Очень полезно.

[Pyk]

получило популярность подключение к реалам двух квазов. Для emu есть такой конфиг

Если что, в Emu80 тоже уже поддерживается...

[ivagor]

Еще исходники плееров для 8080 (1, 2). Вроде еще были, кажется Mick выкладывал, не могу вспомнить.

[svofski]

Ну где ж ды был с этими ссылками до этого? =)
В общем это все плееры STC, то есть более-менее то же самое.

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

Вообще удивительно как много усилий требуется для проигрывания музыки. У нас сейчас есть две противоположности -- модуль + плеер, где вся обработка делается в плеере vs полностью декодированный модуль в виде регистрового дампа. Оба варианта далеки от идеала. Плеер требует вычислений в 2+ раза больше, чем распаковка 14 потоков регистровых дампов в условиях, приближенных к RTOS, а распаковщик регистровых дампов требует вагон памяти. Ну и тоже не совсем бесплатный по времени.

Плеер я не изучал детально, но видно, что там выполняется много движений для доступа к неудобно расположенным данным в таблицах типа чего-нибудь со смещением 7, лукапы по 16-битным ссылкам и тому подобное. Такие вещи как нарочно придуманы чтобы обидеть 8080, которому все это дается со скрежетом зубовным.

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

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

Проверил плеер DemonID7 - тут. (Upd: убрал "эквалайзер"). Большинство фреймов ~ 30 строк, периодически проседает до 45, а один раз поймал на 58.

[ivagor]

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

[Advertiser]

[svofski]

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

        lxi h, song_0
        call gigachad_init

...

        ; песенка
song_0:
        dw song_00, song_01, song_02, song_03, song_04, song_05, song_06
        dw song_07, song_08, song_09, song_10, song_11, song_12, song_13

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

Сколько строк допустимо -- это зависит от ситуации. У меня сейчас так удачно сложилось, что с моим многопоточным плеером получилось засунуть звук туда, где я был уверен, что его вообще не будет. Вообще немного детерминизма плеерам не помешало бы, а то ты думаешь, что он отрабатывает за 35, а тут врдуг бах 58. Это конечно существенно только в случае, когда нужна жесткая привязка к развертке. Если ее нет, то в общем все это не так уж важно.

[ivagor]

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

[reddie]

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

Можно и так, но настолько большой размах, чтобы было заметно на слух, вряд ли достижим. Небольшое плавание есть у любого плеера в компиленном формате редактора (stc, pt и так далее), но даже у древнего плеера от st на Спектруме, где размах был довольно заметен (при визуализации на бордюр), это не ощущалось "ушами". Если по теме, наибольший эффект даст именно переделка плеера конкретно под 8080 с учётом отличий от Z80 ( если речь о переделке), ну или написание с нуля, подразумевающее свой, новый, оптимизированный формат модуля, где "размах" будет сведён к минимуму. В своё время писал компилер и плеер для STPro (Спектрум), и пришлось вдумчиво расставлять переходы и процедуры в плеере, зато размах в итоге был максимум в две строки бордюра, насколько помню, и то это теоретически достижимый потолок, на деле вряд ли встречающийся. А когда новая нота (позиция в паттерне) не извлекалась, стояла искусственная задержка для минимизации "плавания".
Короче, много слов, по итогу - написание грамотного плеера есть наилучший вариант.

[svofski]

Так и сделано в polet4k, например. Но это не решает проблему примерно никак особенно. Если основная логика и плеер вместе не помещаются в кадр, значит уже нет кадровости и приходится делать полукадровость. Причем плеером жертвовать нельзя, потому что ему обязательно быть вызванным 50 раз в секунду и все тут. А если делать что-то такое сложное, то хорошо знать заранее, когда на что сколько времени потребуется. Типа вот плееру надо 60 строк один раз в 50 кадров -- ок, не проблема, если это известно заранее -- можно спланировать дему-игру так, что это пройдет незаметно. А если это неизвестно, то либо приходится резервировать время всегда по худшей планке, а его столько просто нет, или нарываться на срывы периодически.

Про разбиение на вычисление и вывод -- в чем смысл, если и то и другое обязательно делать каждый кадр и все равно мы не знаем, сколько суммарно времени на это уйдет? Максимум что это дает -- убрать джиттер в примерно 1мс (считаю как примерно 1/20 экрана в 1/50 секунды) от того, что плеер вызывается чуть раньше или позже. Это правда слышно?

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

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

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

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

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

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

А что значит "компилер и плеер". Я понимаю плеер, а что в данном случае подразумевается под компиляцией?