introspec, ты чувствуешь мощу? офигеть.
introspec, ты чувствуешь мощу? офигеть.
"наличие готового программного обеспечения для нового компьютера в наши дни имеет мало смысла."
"Еще вопрос - почему на Спектруме большинство звуков на AY булькающие ? Как это исправить ?"
(c) zst
Robus, а каковы твои оценки общего числа созданных в редакторе треков? Есть подробное описание формата? (я не смотрел пока и в ближайшую неделю не смогу, потому задаю глупые вопросы)
"Чувствую" - просто не то слово. Я сейчас в этом дерьме по уши! с головой! нрзб...Сообщение от Hacker VBI
Мне просто интересно, как выглядит чудо-процедура, которая за 168 тактов успевает выполнить 28 операций записи в порты, каждая из которых выполняется не менее 12 тактов.ну, или я забыл, или это был не я
я делал буферизацию в страницу для последнего нг гифта, но там ауты занимали ВРОДЕ тыщу тактов... если ниче не напутал... но точно вроде далеко не 168 тактов.
Наврал, напутал, облажался ... В варианте использования возможности буфферизации 657 тактов. В классическом плеере 168*3=504 такта. Я случайно замерял одну процедуру для одного канала. Прошу прощение ... В OSCOSS используется полный фарш как в инструментах, так и в буфферах. Там получается картина 657+3400 тактов в пике.
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Где-то тут на форуме пролетал плеер с фикс кол-вом тактов ~1000.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Не очень понимаю вот этот упор на скорость. Проигрыватели с полностью предсказуемой времянкой сложнее и нужнее, по-моему. По-моему, нужно больше таких плейеров.
Тот проигрыватель, который уже пролетал (от TmK), насколько я знаю, имеет (имел раньше?) ограничения по исходной музыке. К тому же, несколько идей Robus'a однозначно интересные: например, пре-распаковка.
По-моему, важнее сосредоточиться на по-настоящему важных проблемах человечества. К примеру, тут никто не обсуждает, работает ли хоть один проигрыватель с фикс. кол-вом тактов на скорпионах с задержками. Т.е., работать-то они все будут. Но вот останется ли их фиксированное число тактов - фиксированным?
Если ты изучаешь плеер, то Карл выкладывал старый-классический вариант плеера без возможности буфферизации ... Буфферизация это маленький набор ассемблерных процедур надстраиваемых над плеером в память ниже 49152. Надо собрать красивый вариант плеера без лишних наворотов. Просто у меня подход что ставить задачу основываясь на том сколько сам по себе ест плеер не есть правильно. Нужно ставить задачу вообщем, и тогда можно сделать оптимальный вариант. Например мне в деме OSCOSS надо:
0. буферы
1. стабильность без скачков вообще, синхронизация относительно первого пикселя в инте.
2. гранулярность 4-ре такта, для создания мултиколоров по горизонтали не стабилизируя плеер
3. быстрый доступ к регистрам, что бы всякие эквалайзеры творить
4. возможность разбивать на куски по каналам, используется в зебра-девочке, между полосками у неё играет музыка, примерно в нижней третьи экрана в зависимости от кранча.
Я постарался сделать плеер таким. Что бы каждый мог разбить на нужные ему куски. Кстати, можно вообще выкинуть какой-нибудь канал, допустим если надо только два канала. Плеер во многом универсален и добавляя эффекты в редакторе не надо менять сам плеер. Его устройство очень просто. Музыка разбита на два этапа. У меня не хранятся орнаменты и ноты вообще. При компиляции анализируются часто используемые ноты после этапа обработки орнаментом и всеми эффектами. По сути это набор нот+орнамент+эффект=готовы� � тон из таблицы. Этот тон, по частоте использования, кодируется одним байтом и на ходу распаковки может меняться. То есть кодировка может к середине модуля динамически переползти в набор других нот(тонов). Далее уже не этот тон обрабатывается инструментом. Так же происходит с громкостью. Эта универсальность позволяет мне не менять плеер, но добавлять эффекты. Далее данные разбиты на два типа, команда CALL(симуляция) и сами данные. Вот кодировка-то тонов и CALL'ов динамически впихнута в один байт, или в два, если не хватает одного. Допустим ты где-то в модуле использовал дважды кусочек из четырёх нот, в любом канале, на этот кусок будет выполнен CALL(симуляция), проигрыш и возврат. В компиляторе стоят ограничения по CALL в CALL в CALL, и CALL, который сразу вызывает CALL. Прости за кашу в обяснении, просто такова запутанная логика. Что бы плеер не выпрыгивал более чем на NNN тактов, делается предел на количество CALL'ов за один шаг проигрывания. Сейчас по дефолту стоит 8 CALL'ов. Если поставить только два CALL'а, то объём модуля увеличится, а количество тактов уменьшится. Увеличиваться может до в 2 раза. Предел размера модуля 49152 байта, это предел кодировки смещения CALL'а ...
AAA когда меня режут, я терплю, но когда дополняют, становится нестерпимо.
Был еще от CJ.
Большое спасибо за комментарии, это всё очень полезно. Я сейчас много работаю с точно отмеренным кодом и мне эти соображения очень близки и актуальны. Я пока не решил, какой именно из плейеров буду задействовать; но подглядываю везде, где только могу дотянуться
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
