Mason-AY II ... Music editor ...

[newart]

А ты говоришь, что плеер не быстрый ?

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

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

Опозорюсь ведь ??? Думаешь стоит ? Когда-то я уже занял 21-ое место =))) Надо пару дней, что бы закончить трек.

Стоит. Ты умеешь удивлять.

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

Одно другое не исключает. Недруги все равно твоё демо увидят же?
А друзья... им будет приятнее увидеть демо на пати, в компании дзурзей, а не на ютубе или окошке собственного эмулятора. Я так полагаю.

Тебе нужно хоть раз в жизни выбраться на пати.

[Advertiser]

[psb]

Если мне не изменяет память то только PSB, сделал более быстрый плеер

ну, или я забыл, или это был не я

я делал буферизацию в страницу для последнего нг гифта, но там ауты занимали ВРОДЕ тыщу тактов... если ниче не напутал... но точно вроде далеко не 168 тактов.

[key-jee]

ну, или я забыл, или это был не я

я делал буферизацию в страницу для последнего нг гифта, но там ауты занимали ВРОДЕ тыщу тактов... если ниче не напутал... но точно вроде далеко не 168 тактов.

Мне просто интересно, как выглядит чудо-процедура, которая за 168 тактов успевает выполнить 28 операций записи в порты, каждая из которых выполняется не менее 12 тактов.

[Hacker VBI]

introspec, ты чувствуешь мощу? офигеть.

[introspec]

introspec, ты чувствуешь мощу? офигеть.

"Чувствую" - просто не то слово. Я сейчас в этом дерьме по уши! с головой! нрзб...

[Vitamin]

Robus, а каковы твои оценки общего числа созданных в редакторе треков? Есть подробное описание формата? (я не смотрел пока и в ближайшую неделю не смогу, потому задаю глупые вопросы )

[Robus]

Мне просто интересно, как выглядит чудо-процедура, которая за 168 тактов успевает выполнить 28 операций записи в порты, каждая из которых выполняется не менее 12 тактов.

Наврал, напутал, облажался ... В варианте использования возможности буфферизации 657 тактов. В классическом плеере 168*3=504 такта. Я случайно замерял одну процедуру для одного канала. Прошу прощение ... В OSCOSS используется полный фарш как в инструментах, так и в буфферах. Там получается картина 657+3400 тактов в пике.

[newart]

Там получается картина 657+3400 тактов в пике.

Где-то тут на форуме пролетал плеер с фикс кол-вом тактов ~1000.

[introspec]

Где-то тут на форуме пролетал плеер с фикс кол-вом тактов ~1000.

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

Тот проигрыватель, который уже пролетал (от TmK), насколько я знаю, имеет (имел раньше?) ограничения по исходной музыке. К тому же, несколько идей Robus'a однозначно интересные: например, пре-распаковка.

По-моему, важнее сосредоточиться на по-настоящему важных проблемах человечества. К примеру, тут никто не обсуждает, работает ли хоть один проигрыватель с фикс. кол-вом тактов на скорпионах с задержками. Т.е., работать-то они все будут. Но вот останется ли их фиксированное число тактов - фиксированным?

[Robus]

"Чувствую" - просто не то слово. Я сейчас в этом дерьме по уши! с головой! нрзб...

Если ты изучаешь плеер, то Карл выкладывал старый-классический вариант плеера без возможности буфферизации ... Буфферизация это маленький набор ассемблерных процедур надстраиваемых над плеером в память ниже 49152. Надо собрать красивый вариант плеера без лишних наворотов. Просто у меня подход что ставить задачу основываясь на том сколько сам по себе ест плеер не есть правильно. Нужно ставить задачу вообщем, и тогда можно сделать оптимальный вариант. Например мне в деме OSCOSS надо:
0. буферы
1. стабильность без скачков вообще, синхронизация относительно первого пикселя в инте.
2. гранулярность 4-ре такта, для создания мултиколоров по горизонтали не стабилизируя плеер
3. быстрый доступ к регистрам, что бы всякие эквалайзеры творить
4. возможность разбивать на куски по каналам, используется в зебра-девочке, между полосками у неё играет музыка, примерно в нижней третьи экрана в зависимости от кранча.
Я постарался сделать плеер таким. Что бы каждый мог разбить на нужные ему куски. Кстати, можно вообще выкинуть какой-нибудь канал, допустим если надо только два канала. Плеер во многом универсален и добавляя эффекты в редакторе не надо менять сам плеер. Его устройство очень просто. Музыка разбита на два этапа. У меня не хранятся орнаменты и ноты вообще. При компиляции анализируются часто используемые ноты после этапа обработки орнаментом и всеми эффектами. По сути это набор нот+орнамент+эффект=готовы� � тон из таблицы. Этот тон, по частоте использования, кодируется одним байтом и на ходу распаковки может меняться. То есть кодировка может к середине модуля динамически переползти в набор других нот(тонов). Далее уже не этот тон обрабатывается инструментом. Так же происходит с громкостью. Эта универсальность позволяет мне не менять плеер, но добавлять эффекты. Далее данные разбиты на два типа, команда CALL(симуляция) и сами данные. Вот кодировка-то тонов и CALL'ов динамически впихнута в один байт, или в два, если не хватает одного. Допустим ты где-то в модуле использовал дважды кусочек из четырёх нот, в любом канале, на этот кусок будет выполнен CALL(симуляция), проигрыш и возврат. В компиляторе стоят ограничения по CALL в CALL в CALL, и CALL, который сразу вызывает CALL. Прости за кашу в обяснении, просто такова запутанная логика. Что бы плеер не выпрыгивал более чем на NNN тактов, делается предел на количество CALL'ов за один шаг проигрывания. Сейчас по дефолту стоит 8 CALL'ов. Если поставить только два CALL'а, то объём модуля увеличится, а количество тактов уменьшится. Увеличиваться может до в 2 раза. Предел размера модуля 49152 байта, это предел кодировки смещения CALL'а ...