Комментарии 21
Понастольгировал. Спасибо.
Я правильно понимаю, что именно из-за реализации скролла при игре на Денди, где тайминги отличаются от Famicom и NES, появлялись артефакты (мусор в Eleminator Boat Duel, например, или «дрожание» экрана в Battletoads, или мусорные тайлы в области GUI в некоторых играх)?
Артефакты появляются вроде только если запускать PAL версию игры на денди, в NTSC-версиях всё нормально.
www.emu-land.net/forum/index.php?topic=78279.0
Да, в большинстве игр глюки именно из-за того, что момент переключения скролла неверно определяется. В Battletoads там не только скролл переключается, ещё и гашение луча происходит в ходе кадра, можете в этой и предыдущей статье примеры посмотреть.
Для Elimination Boards (версия игра для региона PAL) строки разделения экрана на слои
в режиме PAL:
в режиме Dendy (сбиты тайминги рассчёта строк, на которых надо разделять экран и тайминг переключения банка памяти с графики GUI на банк с графикой облаков):
www.emu-land.net/forum/index.php?topic=78279.0
Да, в большинстве игр глюки именно из-за того, что момент переключения скролла неверно определяется. В Battletoads там не только скролл переключается, ещё и гашение луча происходит в ходе кадра, можете в этой и предыдущей статье примеры посмотреть.
Для Elimination Boards (версия игра для региона PAL) строки разделения экрана на слои
в режиме PAL:
в режиме Dendy (сбиты тайминги рассчёта строк, на которых надо разделять экран и тайминг переключения банка памяти с графики GUI на банк с графикой облаков):
Спасибо за исчерпывающий ответ!
Но глюки есть и в NTSC-играх. Я два дня назад перепроходил первые TMNT (U-ROM) с флэш-картриджа на Junior I с UM6561F. Периодически на верхней границе игрового экрана и там же, сверху, в экране паузы, возникала тайловая каша. Появлялось это тогда, когда на экране много объектов (например. огненные монстры выпустили много огней и летят «летучие мыши» из этого набора врагов) и экран сдвигается вверх или вниз (лезем по лестнице, к примеру). Насколько помню, было такое и в моем детстве, только версия игры японская была. На оригинальном Famicom этот же картридж с этим же ромом такого не выдает.
Но глюки есть и в NTSC-играх. Я два дня назад перепроходил первые TMNT (U-ROM) с флэш-картриджа на Junior I с UM6561F. Периодически на верхней границе игрового экрана и там же, сверху, в экране паузы, возникала тайловая каша. Появлялось это тогда, когда на экране много объектов (например. огненные монстры выпустили много огней и летят «летучие мыши» из этого набора врагов) и экран сдвигается вверх или вниз (лезем по лестнице, к примеру). Насколько помню, было такое и в моем детстве, только версия игры японская была. На оригинальном Famicom этот же картридж с этим же ромом такого не выдает.
Не могу в эмуляторе такого эффекта добиться. Скорее всего тоже из-за чего-то тайминги сбиваются при скролле.
Бак с мерцающими многими объектами больше похож на железное ограничение, не более 5 (или сколько там было) спрайтов на одной линии.
Это я знаю, он хорошо в Contra Force заметен, да и в TMNT1. Но я говорю не о мерцании спрайтов при превышении лимита, а именно о возникновении мусора в области скролла при большом количестве спрайтов на экране.
С мерцающими объектами это не баг, а фича. Разработчики специально выводят их в каждый раз в обратном порядке, чтобы один кадр рендерились одни объекты, а пропускались другие, а затем наоборот. Это не приводит к другим артефактам, кроме мерцания — лишние спрайты (а точнее даже строки спрайтов), просто будут пропущены.
Каша из тайлов вызывается сбитыми таймингами — где-то в коде игры предполагается, что видеопроцессор находится в определённом месте кадра, а это почему-то не так. Отличий в таймингах денди от других режимов много — wiki.nesdev.com/w/index.php/Clock_rate, точно я не возьмусь предположить, что именно вызывает отличия, вполне возможно, что это связано с Time during which OAM can be written (это как раз время, за которое игра должна успеть записать данные о всех спрайтах на экране).
Каша из тайлов вызывается сбитыми таймингами — где-то в коде игры предполагается, что видеопроцессор находится в определённом месте кадра, а это почему-то не так. Отличий в таймингах денди от других режимов много — wiki.nesdev.com/w/index.php/Clock_rate, точно я не возьмусь предположить, что именно вызывает отличия, вполне возможно, что это связано с Time during which OAM can be written (это как раз время, за которое игра должна успеть записать данные о всех спрайтах на экране).
Лампово.
Огромное спасибо за цикл статей! Читаю с удовольствием.
Хотелось бы еще узнать, каким образом был реализован эффект трассы во всех гонках с видом из кабины/сзади? Например, Rad Racer.
Хотелось бы еще узнать, каким образом был реализован эффект трассы во всех гонках с видом из кабины/сзади? Например, Rad Racer.
Спасибо за великолепный цикл статей. Особенно доставляло мерцание спрайтов в детстве. Я всё на картридж грешил, мол контакты плохие или ещё что. Теперь, когда стал понимать, как отрисованы картинки, стал лучше понимать, откуда эти рудименты. Большинство вызвано ограничением числа спрайтов на линию. Однако некоторые мерцания остались для меня загадкой. Например:
Из-за чего имена полосок индиакторов мерцают?
И ещё вопрос про это ограничение на число спрайтов на линию — в эмуляторах же уже, наверное, можно отрисовывать больше спрайтов на линию и наконец и избавиться от избыточного мерцания в играх. Например тут:
Из-за чего имена полосок индиакторов мерцают?
И ещё вопрос про это ограничение на число спрайтов на линию — в эмуляторах же уже, наверное, можно отрисовывать больше спрайтов на линию и наконец и избавиться от избыточного мерцания в играх. Например тут:
Во FCEUX лимит спрайтов отключается в секции Config→Video→Allow more than 8 sprites per scanline.
В Nestopia отключается по Shift+U.
В остальных эмуляторах не помню, но даже в JNes такая опция была, поищите.
В Nestopia отключается по Shift+U.
В остальных эмуляторах не помню, но даже в JNes такая опция была, поищите.
Из-за чего имена полосок индиакторов мерцают?
Хороший вопрос. У меня глаз настолько замылился с этими спецэффектами, что я даже не замечал этого мерцания в гуи.
Аппаратных причин для этого никаких нет. То, что этот спрайт выводится через кадр просто прописано в коде игры. Разработчики, скорее всего, случайно сделали вывод его той же функцией, которой рендерятся снаряды — там как раз программный вывод через кадр оправдан, чтобы показывать более 8 снарядов в линию (на чётных кадрах выводится одна половина снарядов, на нечётных – другая). Проверю внимательнее к следующей статье.
Но ведь персонаж тоже мигает, получается лимит они все таки превышают?
В бетмене не мигает. Там разработчики реализовали интересную логику (думаю, в других играх это тоже встречается). Важные объекты, например, сам персонаж и босс рисуются в первую очередь, и из-за этого не мерцают, а пули и спрайт гуи — во вторую очередь и программно рисуются через кадр, т.е. мерцают они всегда, и пропускаться при превышении лимита в 8 спрайтов начинают тоже в первую очередь они. Вероятно, разработчики предполагали ситуацию, когда в строке с гуи будет перебор спрайтов, из-за за этого сделали спрайт с буквами «неважным», чтобы зарезервировать место для немерцающих объектов на этой строке.
В Mistume Ga Tooru такой логики разделения нет, поэтому мигает всё. Как упоминали выше, можно в эмуляторе отключить лимит на вывод спрайтов в одной строке, и мерцание пропадёт.
В Mistume Ga Tooru такой логики разделения нет, поэтому мигает всё. Как упоминали выше, можно в эмуляторе отключить лимит на вывод спрайтов в одной строке, и мерцание пропадёт.
Красотища! Пошел искать с детства любимую денди
Мне вот интересно, а почему на некоторых играх некоторые спецэффекты откровенно тормозили, а спрайты исчезали? Это даже давало игроку гораздо больше времени на реакцию. Самый яркий пример — игра Contra Force. Разработчики действительно забили на оптимизацию и ограничение в 8 спрайтов?
Я явно не упоминал в статьях, что число кадров в секунду, отрисовываемое видеопроцессором — постоянное число. Нельзя добиться торможения выводом большого числа спрайтов — видеопроцессор пропускает лишние и будет рендерить дальше с прежней скоростью.
Тормоза связаны с тем, что разработчики написали слишком медленный игровой код, в примере с контрой причина в физическом движке. Там, фактически, реализована честная модель разрушаемости уровня. Любой враг выстрелом может разбить любой разрушаемый блок на уровне (например, пробить гранатой стенку, которая сдерживала катящуюся бочку), а не только попасть в игрока.
Тормоза связаны с тем, что разработчики написали слишком медленный игровой код, в примере с контрой причина в физическом движке. Там, фактически, реализована честная модель разрушаемости уровня. Любой враг выстрелом может разбить любой разрушаемый блок на уровне (например, пробить гранатой стенку, которая сдерживала катящуюся бочку), а не только попасть в игрока.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устройство спецэффектов для игр под NES. Часть 2