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

Читать дальше →

Как я писал в статье про графическую архитектуру Famicom/NES/Денди возможности видеочипа консоли были ограничены сразу с нескольких сторон. Всё изображение обязательно состояло из четырёхцветных тайлов 8x8 пикселей и было всего два банка по 256 уникальных таких тайлов которые могли одновременно быть выведены на экран (при этом бОльшая часть изображения состояла из повторяющихся тайлов). Для игр первого поколения подобных Lode Runner или Bomberman двух этих банков видеоданных хватало на всю игру. Но с усложнением игр 512 уникальных тайлов на кадр резко перестало хватать и были изобретены мапперы переключающие банки на лету чтобы значительно увеличить разнообразие выводимого изображения.
Сегодня мы рассмотрим как переключались эти банки тайлов в первом уровне игры Contra Force чтобы увидеть как все эти технические ограничения с одной стороны обходились, а с другой влияли и в некоторых случаях даже формировали геймплей игр.

Читать дальше →

Одна из первых вещей, которую приходится изучать при освоении низкоуровневого программирования для новой платформы — её карта памяти, то есть где в адресном пространстве находятся ОЗУ, ПЗУ, регистры устройств и тому подобное. Если простота устройства ZX Spectrum, которое можно описать одним предложением — 'нижние 16 килобайт ПЗУ, остальное ОЗУ, экран в начале ОЗУ, весь ввод и вывод через один порт' — позволяет не особо задумываться о самом существовании этого вопроса, то у многих других современных ему платформ дела обстоят несколько сложнее. В особенности это справедливо для NES, карту памяти которой, а также причины именно такой её организации, мы и рассмотрим в этой статье.


Читать дальше →

Пользователи ZX Spectrum и других домашних компьютеров 80-х привыкли к красочным полноэкранным заставкам, показываемым во время загрузки игры. Сама возможность отображения таких заставок им справедливо кажется естественной. И казалось бы, такая довольно мощная для своего времени игровая система, как NES, должна с лёгкостью с этим справляться — ведь показывает же она во время игры прокрутку полного экрана с крупными спрайтами со скоростью 50/60 кадров в секунду. Однако, если задуматься, можно вспомнить, что полноэкранные заставочные картинки едва ли встречались в играх, а по большей части это был чёрный экран с относительно небольшим по площади изображением. Конечно же это не случайно. Углубимся в тему.


Читать дальше →

Изложено в формате 'нет времени объяснять'. Подробное раскрытие каждого небольшого пункта потребует статьи большего объёма, чем этот обзор. Это будет сделано впоследствии, если у читателей обнаружатся конкретные интересы.

Хотите написать игру или демо для NES, Famicom, Денди?

Изучаем. Кладезь актуальной мудрости — NesDev Wiki. Вводные для начинающих — Nerdy Nights на английском, другая на русском. Помним, что старые описания неполны и неточны. Отдельно изучаем 6502. Книг и статей много, поиск начинаем отсюда.

Выбираем между ассемблером и C. Тысяча игр на ассемблере, десятки на C. Код на ассемблере в разы эффективнее, на C пишется в разы быстрее. С ассемлером проще получить помощь зала. Для отчаянных есть экзотика, от BASIC до минимальных Lisp и Python.

Выбираем ассемблер. Три популярных, десятки других. NESASM стар, имеет искусственные ограничения (пришёл с MS-DOS, перепилен с PCE/TG16) и мелкие глюки. Легко освоить, большинство старых уроков под него, выдержит средний проект. Современная альтернатива — ASM6, прост в освоении, но не так популярен. Выбор профессионала — CA65. Мощен и гибок, но сложен в освоении (линкер и конфигурация памяти).

Выбираем компилятор C — CC65. Для работы с железом есть библиотеки neslib и KNES, либо пишем свою. По скорости потолок чистого C — подобие Super Mario Bros. Можно писать частично на C, частично на ассемблере, переписывать фрагменты кода по ходу дела. Очень удобно для прототипирования.

Пишем код. Любимый текстовый редактор, bat или make файлы. Есть развитая IDE для CC65 — NESICIDE, но WIP и почти никем не используется.

Рисуем. Отдельные тайлы редактируем непосредственно в YY-CHR, NES Screen Tool, Tile Layer Pro и других, более сложные изображения импортируем из обычных форматов там же. Для сложных проектов может понадобиться свой велосипед. Без трюков NES не может отобразить полноценную картинку на весь экран, аналога Art Studio не ищите.

Музыка и звуки. Два основных трекера, но нужен проигрыватель, выбирается в зависимости от используемого ассемблера. Пишем в FamiTracker, играем FamiTone или Gradual Games Sound Engine. Пишем в Musetracker, играем MUSE. Штатного плеера FamiTracker хватит для простого демо, но не для игр. По желанию пишем свой плеер, оба трекера имеют текстовый экспорт. Для отчаянных есть древности и экзотика.

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

Для среднего или большого проекта наверняка понадобятся особые конвертеры и утилиты. Пишем на чём угодно, лишь бы работало. Обычно C++ или Python.

Отлаживаем в эмуляторах. Средства отладки развиты в FCEUX и NintendulatorDX. Высокая точность эмуляции в Nestopia и puNES, но отладчика в них нет. Даже самые точные эмуляторы не показывают всех глюков, проверяем во всех четырёх. Если пишем на C с готовой низкоуровневой библиотекой, на железе наверняка заработает. Выжимаем максимум на ассемблере — обязательно проверяем на железе при помощи Flash-картриджей (EverDrive N8, InviteNES, PowerPak — ищем в интернете) или самодельного картриджа и программатора ПЗУ.

Успехов!