Вывод данных регистров идёт не напрямую в APU, а в промежуточный буфер. Сначала выводятся данные регистров для музыки. Далее для каждого из виртуальных каналов эффектов для Pulse и Noise каналов проверяется текущая моментальная громкость канала эффекта, если она выше той, что записана в буфер, значения соответствующего канала APU перезаписываются данными для эффекта; для Triangle перезапись идёт всегда, если он активен (т.к. громкость у него бинарная, вкл-выкл). Таким образом в итоге в буфере остаются данные только самых громких частей, если эффект громче музыки — он глушит соответствующие каналы музыки, если эффекты одинаковой громкости, приоритет у старшего канала эффектов. Это не самое оптимальное решение, но оно вполне рабочее, и в принципе нет однозначно лучшего решения, у каждого есть свои плюсы и минусы.
Новых мелодий у меня нет. FamiTone и всё ему сопутствующее опубликовано под лицензией CC0/PD, можно делать что угодно без ограничений и без указания авторства.
Я без понятия, видимо так. Надо понимать, что это старый проект, в который на протяжении многих лет предлагали изменения какие-то люди, ожидая, что я всё время только о нём и думаю — но мне, чтобы ответить на любой вопрос, теперь нужно разбираться столько же времени, сколько и любому другому человеку. Это вообще типичная история поддержки homebrew-проектов — первые несколько лет после выхода они не нужны и не интересны никому. А когда успел разочароваться в результатах, сделать десяток других, заняться вообще принципиально другими делами в жизни, люди вдруг начинают писать — а почему эта запятая не на том месте? А почему в конвертере в версии XYZ пятилетней давности было $30, а в версии XYZZ четырёхлетней давности стало $c0, но код плеера не поменялся? А почему окно конвертера открывается и сразу закрывается?
Версия CA65 автоматически генерируется из мастер-исходника для NESASM, вероятно отсюда растут ноги у проблемы. Вероятно, когда и если я с этим сталкивался сколько-то лет назад, я один раз пофиксил по месту и забыл. Но скорее просто за всё это время данные дефайны ни разу никому никаким образом не понадобились, включая меня — в рабочем коде пары текущих проектов они у меня точно в таком же виде, как в цитате выше.
Да, переменные плеера занимают не всю страницу. В neslib они традиционно размещаются в странице стека, а также туда идёт буфер палитры, т.к. сам аппаратный стек в реальных программах не превышает 32 байт.
Есть ассемблеры без линкеров, есть с линкерами. Для того, чтобы были упоминания сегментов, нужно, чтобы исходник был под ассемблер с линкером. SjAsmPlus — ассемблер без линкера. В среде любителей-энтузиастов это более типичная архитектура ассемблера, т.к. её проще сделать (любители же сами эти ассемблеры и писали) и проще пользоваться в рамках одной целевой платформы. Из любительских кросс-ассемблеров с линкером сходу вспоминаю разве что WLA DX.
В SjAsmPlus код в банках размещается как раз ORG'ами в одни и те же адреса и сохраняется в бинарники по мере трансляции, т.е. в те моменты, когда в нужных адресах виртуальной памяти сгенерирован нужный код, а дальше по ходу трансляции он может быть перезаписан.
CA65/CC65 — пакет не для конкретно NES, а для любых систем на 6502 (и частично 65816) в принципе, изначально для восьмибитных Atari (1989 год, между прочим). Соответственно сегментная модель в линкере позволяет задать любую карту памяти для любого компьютера с этим процессором. Также бывают ситуации, когда часть памяти кода переключаемая (разная память в одних и тех же адресах, т.е. банки), часть обязательно должна быть фиксированной, есть разные виды памяти, и всё это дело сохраняется в какой-то образ определённого формата — всё это легко позволяют задать сегменты (для NES: хидер iNES, расположение ОЗУ, банки PRG и CHR).
Лет десять назад я сделал три вещи, которые оказались весьма востребованными в тот момент, и с помощью которых с тех пор была создана добрая половина homebrew для NES:
— Конвертер-редактор графики и экранов, а впоследствии также и составных спрайтов — NES Screen Tool, с довольно корявым, но вполне человеческим лицом. До этого были только редакторы тайлов типа Tile Layer Pro и YY-CHR, а также дикие утилиты под DOS, что очень затрудняло подготовку графики для игр. Альтернативы ему не появилось до сих пор (а надо).
— Библиотеку FamiTone, которая позволила легко и просто добавлять музыку и (решающий фактор) звуковые эффекты в игры, делая их в человеческом FamiTracker. В этом также большая заслуга jsr, Gradualore и rainwarrior, которые добавили и развили поддержку кастомных экспортёров из FamiTracker. До этого не было готового плеера, который можно было просто взять и вставить — все либо изобретали велосипед, обязательно включающий написание музыки в hex-кодах, либо приватно делились кодом. К тому же, в тот момент предпочтения в комьюнити касательно кросс-ассемблеров делились на три равные части, NESASM/asm6/CA65, код между которыми переносить довольно затруднительно, а я поддержал все три сразу. С тех пор появилось несколько альтернатив (в том числе форков моего кода), FamiTone ещё в лидерах, но его начинает теснить решение от Gradualore, которое встроили в NES Maker.
— Библиотеку neslib, которая позволила легко и просто писать на C. Ранее на сцене ходили настроения, что ничего путного сделать на C невозможно, не стоит даже и пытаться — никто и не пытался. А я видел, что делают Mojon Twins с компилятором C на ZX (как известно, ныне чурерра заполонила), и показал, что так можно было. Также я привлёк самих Mojon'ов, чтобы они показали класс (Sir Ababol и другие игры). Это в свою очередь сподвигло nesdoug'а не только самому начать писать на C, но и сделать серию туториалов, которые потом перевели на русский.
Соответственно, теперь куда не клюнь — ваш пострел везде поспел.
файл в таком формате состоит минимум из трёх идущих друг за другом секций
Всё же минимум из двух. Секция графики часто может отсутствовать, это типично для UNROM-подобных конфигураций. Даже базовый NROM в принципе может не иметь секцию графики, а использовать CHR RAM либо даже собственное ОЗУ видеоконтроллера (на железе есть трюк, позволяющий замаппить 2K видеопамяти как память тайлов).
NESICIDE крайне малопопулярен, за исключением автора его почти никто не использует, а процент русскоязычных разработчиков для NES сам по себе крайне невелик, так что наличие около нуля русскоязычных пользователей до настоящего момента было вполне ожидаемо. По причине непопулярности заточенных именно под него статей с пошаговыми инструкциями я не припоминаю.
Со времён этой заметки появилось ещё некоторое количество статей и на английском и на русском. Но писать всё равно стоит. Во-первых, время идёт, инструменты меняются, обновляются и устаревают. Во-вторых, иметь варианты всегда хорошо, не пошло дело по одному гайду (автор непонятно объясняет, читатель почему-то не понимает) — хорошо иметь другой. Ну и просто лишнее напоминание публике о том, что есть такая возможность, писать под подобные старые платформы.
Разные подходы и организация рабочего процесса. Я пишу всё одновременно, многое придумывая и изменяя на лету, ну и в одно лицо. Для видеоредактора же надо сначала придумать сделать все эффекты, полностью подготовить музыку, потом кодер может отдыхать, пока набирается скрипт, но потом он вручную переводит скрипт в нужные данные.
Я не знаю, какие сборочные процессы у других, свои я всегда полностью автоматизирую. Поэтому для меня постоянная перекомпиляция выглядела бы так: открыт трекер и Notepad++, поставил-изменил нужные маркеры, Ctrl+S в трекере, Ctrl+F6 в Notepad++, и секунду спустя результат виден в эмуляторе. Вроде удобнее не придумаешь.
Во-первых, офигенное демо. Смотрел трансляцию в ночи, ожидая показа 10 часов, и не пожалел — для меня это лучшая работа всего пати. Во-вторых, офигенный making of! Очень интересно узнавать креативный процесс, как рождаются идеи, как преодолеваются творческие трудности. С кодом-то всё понятно, бери да пиши, знать бы что.
Я думаю, я бы для супер-точного фикса при обычном одном AY попробовал бы сделать маркеры, используя для этого второй трек (как для TS). VT может играть два трека синхронно, и формат у него текстовый — можно заглушить второй чип, писать в паттернах второго трека любую дичь, а потом сделать простой парсер этой дичи в нужные данные.
Наведите курсор на любую метку и выберите Go > Go to Definition — и вас перенесёт к процедуре, на которую назначена эта метка! По умолчанию, у этой функции почему-то нет горячей клавиши
byuu конечно расстроится, узнав, что он так и не смог понять SA-1.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.
До R-Type на горизонтальные шмапы очень сильно повлияли Defender и Scramble (обе 1981), у них были несметные полчища клонов. Но это было на поколение раньше. Жанр оформился в Gradius (1985), а R-Type сделал примерно то же, что Galaga относительно Space Invaders или Arkanoid относительно Breakout — поднял планку на качественно новую высоту.
Ещё интересное явление — клоны R-Type. Их не так много, но хватает. Из классных, которые вспоминаются сходу — Pulstar и Blazing Star на Neo-Geo, они вполне на уровне Leo.
И надо отметить что платформа PC Engine помимо двух портов R-Type известна тем, что попала в самый пик популярности горизонтальных и вертикальных шмапов. Там днём с огнём не найти платформеров типа Mario, зато наверное каждая третья игра — шмап, и многие очень высокого качества.
Новых мелодий у меня нет. FamiTone и всё ему сопутствующее опубликовано под лицензией CC0/PD, можно делать что угодно без ограничений и без указания авторства.
Версия CA65 автоматически генерируется из мастер-исходника для NESASM, вероятно отсюда растут ноги у проблемы. Вероятно, когда и если я с этим сталкивался сколько-то лет назад, я один раз пофиксил по месту и забыл. Но скорее просто за всё это время данные дефайны ни разу никому никаким образом не понадобились, включая меня — в рабочем коде пары текущих проектов они у меня точно в таком же виде, как в цитате выше.
И в теле объявления заголовка использовать эти определения, типа .byte NES_PRG_BANKS.
В SjAsmPlus код в банках размещается как раз ORG'ами в одни и те же адреса и сохраняется в бинарники по мере трансляции, т.е. в те моменты, когда в нужных адресах виртуальной памяти сгенерирован нужный код, а дальше по ходу трансляции он может быть перезаписан.
— Конвертер-редактор графики и экранов, а впоследствии также и составных спрайтов — NES Screen Tool, с довольно корявым, но вполне человеческим лицом. До этого были только редакторы тайлов типа Tile Layer Pro и YY-CHR, а также дикие утилиты под DOS, что очень затрудняло подготовку графики для игр. Альтернативы ему не появилось до сих пор (а надо).
— Библиотеку FamiTone, которая позволила легко и просто добавлять музыку и (решающий фактор) звуковые эффекты в игры, делая их в человеческом FamiTracker. В этом также большая заслуга jsr, Gradualore и rainwarrior, которые добавили и развили поддержку кастомных экспортёров из FamiTracker. До этого не было готового плеера, который можно было просто взять и вставить — все либо изобретали велосипед, обязательно включающий написание музыки в hex-кодах, либо приватно делились кодом. К тому же, в тот момент предпочтения в комьюнити касательно кросс-ассемблеров делились на три равные части, NESASM/asm6/CA65, код между которыми переносить довольно затруднительно, а я поддержал все три сразу. С тех пор появилось несколько альтернатив (в том числе форков моего кода), FamiTone ещё в лидерах, но его начинает теснить решение от Gradualore, которое встроили в NES Maker.
— Библиотеку neslib, которая позволила легко и просто писать на C. Ранее на сцене ходили настроения, что ничего путного сделать на C невозможно, не стоит даже и пытаться — никто и не пытался. А я видел, что делают Mojon Twins с компилятором C на ZX (как известно, ныне чурерра заполонила), и показал, что так можно было. Также я привлёк самих Mojon'ов, чтобы они показали класс (Sir Ababol и другие игры). Это в свою очередь сподвигло nesdoug'а не только самому начать писать на C, но и сделать серию туториалов, которые потом перевели на русский.
Соответственно, теперь куда не клюнь — ваш пострел везде поспел.
Я думаю, я бы для супер-точного фикса при обычном одном AY попробовал бы сделать маркеры, используя для этого второй трек (как для TS). VT может играть два трека синхронно, и формат у него текстовый — можно заглушить второй чип, писать в паттернах второго трека любую дичь, а потом сделать простой парсер этой дичи в нужные данные.
Вообще забавно заявление, что исправлена игра, хотя она просто запущена на более быстром процессоре, да и весь разговор по сути про SA-1. А ведь можно было бы заморочиться и реально оптимизировать код, чтобы игра перестала тормозить без привлечения дополнительного процессора. Во множестве игр на SNES основные тормоза из-за очень своеобразной организации списка спрайтов (биты координат разбросаны). Если писать в лоб, получается множество сдвигов и битовых операций. Помогает держать в памяти список спрайтов в более удобном формате, а блок для OAM формировать один раз в конце кадра развёрнутым циклом. В Gradius не смотрел, но скорее всего эта проблема присутствует и там.
Ещё интересное явление — клоны R-Type. Их не так много, но хватает. Из классных, которые вспоминаются сходу — Pulstar и Blazing Star на Neo-Geo, они вполне на уровне Leo.
И надо отметить что платформа PC Engine помимо двух портов R-Type известна тем, что попала в самый пик популярности горизонтальных и вертикальных шмапов. Там днём с огнём не найти платформеров типа Mario, зато наверное каждая третья игра — шмап, и многие очень высокого качества.