Рекомендую также обратить внимание на Sega Game Gear. Это почти то же самое, но ещё плюс сотня-другая игр. Только придётся заморочиться с расширением отображаемой части уровня, но это многократно делалось любителями, они нередко адаптировали игры, в обе стороны.
WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).
Меня никогда не интересовало программирование само по себе — красота кода и прочие подобные штуки. Программирование для меня всегда остаётся просто необходимым инструментом — хочу делать игры, значит надо писать код. Вероятно поэтому разные процессоры не доставляют мне особых проблем, и я не заморачиваюсь размышлениями, где что лучше и где проще-сложнее, просто пишу на том, что есть. Сложность кода вообще штука такая — если для решения задачи нужен какой-то трюк (чтение стеком на Z80 или 16-битное сравнение со знаком на 6502), это не сложность и не неудобство, это один раз научился и дальше применяешь по необходимости, а то и просто заворачиваешь в макрос и забываешь. Сложность кода начинается скорее на алгоритмическом уровне, а на уровне реализации алгоритма на ассемблере это одинаково не сложно и не просто, это просто есть как есть.
Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.
Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):
Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):
А вот в копировании разница уже не такая большая, всего 6 условных единиц.
Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.
Я предполагаю, что теоретически для фиксированной проекции каждой конкретной точке экрана должен однозначно соответствовать конкретный статичный вектор. Т.е. если мы смотрим на точки ближе к центру, там линия стены идёт под острым углом к зрителю, а у точек ближе к углам экрана линия идёт в направлении угла. Значит по экранным координатам угловой точки всех восьми вариантов углов стен нижнего слоя можно однозначно определить, какую линию надо нарисовать.
Можно заготовить карты тайлов с заранее нарисованными фиксированным набором графики всеми возможными углами, размером типа 4x4 тайла для четверти всех возможных случаев (т.к. три четверти экрана можно отзеркалить), и каждый кадр дорисовывать в карту тайлов каждый угол. Т.е. нужен массив размером в четверть экрана с индексами нужных тайлов (8 бит), это будет порядка 128*112=14 килобайт, плюс набор карт тайлов углов (256 карт 4x4 займёт 4К, 256 углов определённо должно хватить) — по меркам платформы это совсем немного для такого киллер-эффекта.
В общем, идеи есть, и наверное мой вариант сработает и будет достаточно быстрым, но я не уверен, что в Red Zone сделано именно так. Это такой эффект, где надо поэкспериментировать и предусмотреть много разных мелочей. Его реализация не читается однозначно по визуальному анализу, в отличие от большинства приставочных эффектов.
Ну смотри, у тебя только имхо. А я говорю исходя из практического опыта. Почему люди совершенно не хотят слушать тех, кто имеет непосредственный опыт, предпочитая абстрактное чтение док и своё мнение — для меня загадка. Но таково положение вещей, тот же многониковый товарищ постоянно расстраивался на эту тему.
Когда ты пишешь под SNES, ты не думаешь — а вот есть другой процессор, ах, сколько там РОН, какие там 32-битные операции и смещения. У тебя есть конкретный процессор, такой, какой он есть. Это данность. И ты пишешь для него код, как умеешь, настолько эффективно, как умеешь, чтобы решить конкретную задачу. Практика показывает: все задачи нормально решаются и там и там. Конечно, если у тебя опыт программирования на Z80 или M68K, ты будешь думать — как неэффективно писать на 6502/65816, там так мало регистров. Потому что у тебя нет понимания, что там принципиально другая парадигма, что там просто пишешь иначе, но в результате получаешь те же результаты. Когда ты уже знаешь и умеешь, ты не думаешь, как это сложно в сравнении, потому что тебе уже не сложно это делать.
Я много раз предлагал всем желающим поучаствовать в написании сравнительных тестов, Z80/6502, M68K/65816. Желающих за много лет почему-то не нашлось ни разу. И думаю, это не сработает, потому что знающий только одну архитектуру будет продолжать придерживаться своих взглядов на эффективность, т.к. по прежнему не понимает другую сторону ('ах, ты добился такого же результата, но мне не нравится твой непонятный код, я считаю его некрасивым'), а у знающего обе вопросов про сравнение уже не возникает.
Это всё теория. На практике и там и там одинаково сложно сделать игру типа GH, и, повторяюсь, одинаково и там и там проблема не в коде, не в операциях, и не в системе команд. В GH нет совершенно ничего необычного в плане кода, просто аккуратно спланированные растровые эффекты, грамотное использование двух слоёв фона. На SNES есть те же самые два слоя фона, и можно сделать те же самые эффекты. Причём делаются они чуть проще, т.к. есть HDMA.
Самая главная проблема на SNES — откровенно неудачная система спрайтов. Если не сделать менеджер списка спрайтов грамотно, будут тормоза, наблюдаемые во многих играх. У большинства программистов тех лет просто не было опыта и времени разбираться, как решать эту проблему (но некоторые решали). Не выглядящие крутыми демки также показывают, что проблема решаема, а блог описывает, как именно. Я также пришёл к подобному решению, увидел изыскания этого товарища уже после этого.
Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
Вот indoor-эффект я до сих пор не смог раскусить до конца (аналогично ещё в Toy Story, но попроще). Т.е. я знаю, как это делается в общем случае, не на SMD, но если большинство эффектов из игр на SMD/SNES я повторить на них же готов и точно знаю, как это сделать, то этот — нет. Я бы стал делать честный рендер углов стен с подгрузкой графики в видеопамять, но они обходятся (довольно большим) набором статичных тайлов.
Вероятно память буфера строки стоила бы слишком дорого в плане места на кристалле. В NES динамическая память OAM (описание спрайтов, X/Y/тайл/палитра) размером 2x256 байт занимает аж четверть кристалла PPU. Для варианта с буфером строки понадобилось бы ещё 2x256 байт, плюс возможно логика заняла бы сравнимо или больше, чем логика со сдвиговыми регистрами.
Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
Вот прямо чувствую, что нет полного понимания эффекта, и моё объяснение не очень понятно. Конечно не получится без смещения по вертикали, суть эффекта в этом и стоит.
Попробую объяснить ещё раз. Эффект состоит из двух частей.
Первая часть 'рисует' залитый круг и трапецию в буфер в основном ОЗУ. Это самая обычная техника рисования полигона. В буфере для каждой строки всего два значения — самая левая точка и самая правая точка отрезка (xmin,xmax). Рисуем круг алгоритмом Брезенхема (потому что быстро): получаем координату точки, смотрим строку в буфере. Если точка нужна левее, чем левая — значим меняем в буфере на более левое значение. Если нужна правее, чем правая — тоже. Таким образом получается буфер ширины и смещения горизонтальных линий на экране, из которых состоит залитая фигура. Эта техника позволяет рисовать только выпуклые фигуры, то есть букву H ей не нарисовать (нужно два отрезка в пределах одной строки). Более сложное объяснение, если вдруг формулами понятнее, чем на пальцах: www.enlight.ru/faq3d/articles/24.htm
Вторая часть просто решает задачу быстрого вывода требуемых линий на экран, имея в распоряжении только железо SMD. С помощью изменения смещений слоя фона по HBlank мы можем вывести любую строку слоя фона в любую строку экрана. Заранее рисуем в слое фона все возможные ширины отрезков, какие нам понадобятся (т.е. от 1 до N пикселей). Теперь смотрим по буферу, подготовленному первой частью эффекта — надо отрезок шириной в три пикселя? Выводим третью строку слоя фона, где как раз и есть отрезок шириной в три пикселя. При этом смещаем её по горизонтали в нужное место экрана. Если у нас отрезок шириной в три пикселя не в одной строке экрана, а во многих — значит во все эти строки выводим строку фона с тремя пикселями.
Эффект с прожектором в общем-то прост. Рисуем в слое графики фона как бы треугольник — сначала один пиксель, потом два, потом три, и так далее до полной ширины. Теперь с помощью прерывания по HBlank в каждой строке мы можем вывести в эту строку линию нужной ширины — просто выбираем нужное вертикальное смещение в слое фона для задания ширины линии и нужное горизонтальное смещение для её позиционирования по горизонтали. А имея возможность вывода линий любой ширины мы можем нарисовать на экране любую выпуклую фигуру, это самый обычный рендер полигона (буфер xmin-xmax, рисуем круги и линии алгоритмом Брезенхема).
В Clockwork Tortoise скорее всего были выходцы с демосцены, как в Zyrinx. Либо Jesper Kyd на них так повлиял.
У Sega был большой опыт с аркадами, они по сути просто немного урезали одну из своих аркадных платформ. К сожалению, они видимо слегка спешили, и упустили пару моментов, которые сделали бы железо ещё удачнее — в частности, 64-цветная палитра и 9-битный видео ЦАП очевидный просчёт, сделать чуть больше цветов было бы не сильно дороже, но явно лучше. И не сделали прерывание Z80 от таймера YM2612, по сути это всего один проводок, но он очень упростил бы жизнь.
У Nintendo с опытом было похуже. Вообще инженерная работа была проделана очень хорошая, в том плане, что огромная куча наворотов очень аккуратно и красиво организована в наборе регистров, и предусмотрены некоторые очень полезные и крутые фичи (HDMA, window mask, color math). Но там видимо сильно давил прошлый ограниченный опыт и идея сделать обратную совместимость, которую на полпути отбросили, а наследие осталось и сильно повредило результату: такие же карты тайлов, как на NES (ещё одна местная боль), крайне ограниченные спрайты и прочие странности. В общем-то даже 65816 и SPC700 скорее всего были выбраны по причине начального курса на обратную совместимость и простоту перестройки программистов на новую платформу (SPC700 тоже очень похож на 6502, но дурные официальные мнемоники маскируют этот факт).
В GH нет рендера в видеопамять, там всюду готовые тайлы. Т.е. формат хранения графики с точки зрения переносимости этой игры непринципиален. Битпланы и плюс и минус, что-то рендерить сложнее, что-то проще (если надо всего 2-4 цвета, например). С практической точки зрения на SNES тоже всегда всё 16-цветное, фоны в 4 и 256 цветов используются очень редко.
Лично мне гораздо больше нравится писать под 65816, чем под 68000, никакой боли. Для понимания надо просто попробовать, трудно объяснить на словах, почему 3 РОН (на самом деле не сильно-то они общего назначения, по сути РОН всего один) не являются проблемой. Так только кажется, если смотреть издали, с других колоколен (8080 и 68K). Если искать проблемы в архитектуре 6502, это прежде всего ограниченность косвенной адресации, т.к. если надо иметь полностью динамический указатель для двух вещей одновременно (типа источник и приёмник в LZ-распаковщике), начинаются пляски с регистром Y (косвенная адресация всегда идёт по (ZP),y).
Вычислительная мощь однозначно сопоставимая, никаких сомнений у меня нет. Несопоставимо — это когда разница в разы, такого тут и близко нет. Реальная боль в заднице на SNES — вовсе не процессор, а видеоконтроллер, в особенности система спрайтов. Ладно битпланы, но ограничение на 1024 тайла на слой фона, только два формата спрайтов одновременно, только 512 тайлов на спрайты (!!!!), расположение тайлов спрайтов, разбросанные по двум спискам биты OAM, и много чего ещё — вот это реально очень напрягает.
Маегава, конечно, погорячился. Что-что, а процессор является наименьшей проблемой на SNES, писать под него очень легко — это же чуть улучшенный 6502, едва ли можно придумать процессор проще. Да и про торможение боссов, это смотря как написать. На SNES сцене есть один человек (не могу сейчас вспомнить и найти, он постоянно менял ники), очень любит спорить именно на эту тему со случайными прохожими. Он написал демку Gunstar Heroes-подобной игры, там у него и составные объекты, и вращение — всё нормально, ничего не тормозит. Исходя из собственного опыта, я тоже уверен, что GH на SNES написать можно было без особых проблем.
Была всего одна игра с дополнительными 2K VRAM для карт тайлов, Gauntlet. Остальные выкручивались как могли. Проблема с диагональным скроллом при двух картах тайлов только в том, как скрыть область дорисовки новых тайлов.
Самый простой вариант диагонального скролла в SMB3 и Felix The Cat — вертикальная раскладка карт тайлов. По вертикали вообще ничего не дорисовывается, уровень всего два экрана в высоту (минус высота панельки снизу). По горизонтали дорисовывается прямо на экране (т.к. карта тайлов в ширину с экран). SMB3 просто не заморачивается по этому поводу, дорисовка видна визуально на краях экрана. Felix скрывает два вертикальных столбца на краях экрана, чтобы сделать дорисовку незаметной — слева аппаратной фичей выключения рендеринга в левом столбце, а справа столбцом чёрных спрайтов (т.к. аппаратной фичи для правого столбца не предусмотрено).
В других играх, где уровень выше двух экранов, стоит вопрос, скрывать вертикальную или горизонтальную дорисовку. Если выбрать горизонтальную раскладку экрана, легко скрыть горизонтальную дорисовку за экраном, но видна вертикальная. Её можно отсечь с помощью панельки или включения/гашения рендера позже начала/раньше конца кадра (обрезав высоту на 16 пикселей). Если не ошибаюсь, с гашением сделано в Jurassic Park. Можно сделать раскладку вертикальной, тогда вертикальная дорисовку получается скрыта, но видна горизонтальная. Её можно скрыть как в Felix, или оставить видимой как в SMB3 (нередко так и делали).
Часто не скрывали дорисовку просто потому что на старых ЭЛТ телевизорах края растра уходили за края видимой области экрана. Потому на всех ТВ-приставках времён ЭЛТ в гайдлайнах есть требования к safe area — к соблюдению области, в которой изображение будет гарантировано видимым. Т.е. за пределами safe area нельзя размещать критичную информацию типа очков или статуса. На NES это отступы примерно по 16 пикселей по вертикали и 8-16 по горизонтали.
Можно сделать горизонтальную раскладку, тогда область горизонтальной дорисовки скрыта, а вертикальной видна.
Звуковые чипы SN76489, TIA, AY-3-8910, POKEY появились довольно-таки задолго до IBM PC, в 1977-79 годах. Потому что игровым системам определённо был нужен звук, а PC в качестве игровой системы долго не рассматривался. Спикер PC предназначался для системных целей, и вероятно был сделан на канале таймера не из необходимости разгрузки процессора, а просто потому что таймер уже был и оставался лишний канал (другие каналы используются для действительно важных вещей — прерываний по таймеру и регенерации ОЗУ).
Огибающая в AY не для обогащения тембров. Она именно огибащая, как и ADSR — для задания изменения громкости во времени. Но в этих целях она оказалась слишком примитивной (в 1978 не особо понимали, что именно нужно). А богатые тембры из неё начали получать уже гораздо позже, лет через 12 после появления чипа — оказалось возможным запускать её на очень высокой частоте, таким образом, что периоды повторения сливались в тон (пилу или треугольник), а также смешивать с обычным каналом тона, что даёт вырожденный случай амплитудной модуляции (тон огибающей маскируется прямоугольным каналом).
В SID главная фишка — аналоговый фильтр, очень сильно окрашивающий звук. По сути приближение к архитектуре классических аналоговых синтезаторов. Аналогичную архитектуру, DCO и общий для всех каналов фильтр, имел, например, синтезатор Korg Poly 800 (1983).
В NES нет короткого буфера PCM. Там есть DPCM — однобитное кодирование 7-битного звука, в целях сжатия ценой сильных искажений, с аппаратным проигрывателем (читает память, декодирует, выводит в ЦАП, всем этим немного затормаживает процессор). Напрямую DPCM доступно 16 КБ адресного пространства ПЗУ, в которое можно включать банки посредством маппера (если есть). Зацикливать DPCM формально можно, но по самой природе кодирования нормального чистого цикла в сложных сэмплах не получится (будет сильно щёлкать переход), только если не специально сконструировать сэмпл буквально побитно (тогда можно вымучить, например, чистую пилу).
FM-синтез в чипах на самом деле PM, фазовая модуляция, близкая по сути вещь, но гораздо проще реализуемая. Т.к. это PM, именно вибрато, возможное в FM, толком не получить. Смысл этих видов синтеза в получении гармоник. Гармонический состав сигнала определяет его тембр, чем больше гармоник, тем сложнее и интереснее (реалистичнее в том числе) тембр. Две синусоиды при аддитивном синтезе были бы всего двумя гармониками, а при модуляции их получается намного больше.
Что забавно, PS2 уже считается ретро-платформой. Из поколения до 2000-х ещё интересен Dreamcast, любительская разработка для него относительно доступна, там выходит немало крутых homebrew-проектов (или даже можно назвать их инди).
К слову, на PS2 тоже применялась куча весьма интересных трюков. Например, в MGS (игра на последней картинке) есть блестящие, отражаюшие в себе всю обстановку полы. Как они сделаны: коридор скопирован и перевёрнут по линии пола, с пониженной детализацией, также перевёрнуты и отрисованы ниже линии пола модели персонажей, а сам пол сделан полупрозрачной текстурой, она затеняет нижнюю копию, и создаётся эффект отражения. И там много подобных маленьких трюков, в результате игра выглядит весьма круто для тех лет (версия на PS2 лучшая, во всех портах и римейках много чего урезано или испорчено) и при этом идёт на 60 FPS.
Если мне не изменяет память, в Q1 на PC была линейная аппроксимация, там каждые N (16?) пикселей считалось точно, а между ними аффинная проекция. В результате текстуры почти не плыли, только если специально не искать такие моменты. На PS1 под закат пришли к подобным техникам, но грубее, как позволял GPU — разбивая крупные (ближние?) полигоны на множество мелких. Поэтому в поздних играх текстуры плывут значительно меньше.
WLA DX конечно стандарт, и в общем-то хорош, но очень уж глючный, особенно в части редких процессоров. Так что его использования стараются избегать, и именно по причине проблем с WLA наделали немало альтернатив. Он с тех пор вроде как исправился, но осадочек-то остался. Сам до сих пор использую его для SNES (только для 65816), но это вынужденная мера, tcc-816 завязан на него (адски глючная связка).
Это к тому, что мне просто по образу мышления не приходят в голову абстрактные типовые задачи. У всех платформ помимо процессора также и своя специфика во всём остальном, в частности в видеосистеме, где в основном критична скорость кода. Где не критична, там я особо не оптимизирую, пока не возникает реальная необходимость, потому что важнее закончить проект в целом и не перегореть (make it work, make it pretty), чем закопаться с головой в несущественных для общей картины деталях. Как правило в целой игре не так уж много узких мест, где нужно выжимать максимум.
Наверное, для тестов производительности нужно придумать виртуальную систему, где всё железо одинаковое, разный только процессор. Например, для удобства, Pentagon (потоиу что полностью софтовая графика, есть необходимость жёсткой оптимизации, и нет торможения по всей памяти), но с 6502 на 1.75 МГц. Для начала можно посмотреть предельную пропускную способность, развёрнутый цикл, задачи максимально быстрой очистки экрана и максимально быстрого заполнения экрана произвольной графикой (как мы делаем во фреймовых листалках):
Очистка (lps — сколько раз выполнится такой за секунду на соответствующей частоте процессора):
Разница в скорости на треть. В размере очень большая, что ожидаемо — код на 6502 всегда заметно многословнее.
Зарисовка:
А вот в копировании разница уже не такая большая, всего 6 условных единиц.
Эти тесты не показывают ничего конкретного, кроме одного: не всё так однозначно, как кажется. Где-то проигрыш 6502 очень заметен, где-то результат очень близкий. По практическим задачам (эффекты на ZX и C64, порты биперных движков с ZX на Atari) мы давно уже знаем, что разница по мере роста сложности алгоритмов сводится к минимуму, всюду возможно примерно одно и то же.
Можно заготовить карты тайлов с заранее нарисованными фиксированным набором графики всеми возможными углами, размером типа 4x4 тайла для четверти всех возможных случаев (т.к. три четверти экрана можно отзеркалить), и каждый кадр дорисовывать в карту тайлов каждый угол. Т.е. нужен массив размером в четверть экрана с индексами нужных тайлов (8 бит), это будет порядка 128*112=14 килобайт, плюс набор карт тайлов углов (256 карт 4x4 займёт 4К, 256 углов определённо должно хватить) — по меркам платформы это совсем немного для такого киллер-эффекта.
В общем, идеи есть, и наверное мой вариант сработает и будет достаточно быстрым, но я не уверен, что в Red Zone сделано именно так. Это такой эффект, где надо поэкспериментировать и предусмотреть много разных мелочей. Его реализация не читается однозначно по визуальному анализу, в отличие от большинства приставочных эффектов.
Когда ты пишешь под SNES, ты не думаешь — а вот есть другой процессор, ах, сколько там РОН, какие там 32-битные операции и смещения. У тебя есть конкретный процессор, такой, какой он есть. Это данность. И ты пишешь для него код, как умеешь, настолько эффективно, как умеешь, чтобы решить конкретную задачу. Практика показывает: все задачи нормально решаются и там и там. Конечно, если у тебя опыт программирования на Z80 или M68K, ты будешь думать — как неэффективно писать на 6502/65816, там так мало регистров. Потому что у тебя нет понимания, что там принципиально другая парадигма, что там просто пишешь иначе, но в результате получаешь те же результаты. Когда ты уже знаешь и умеешь, ты не думаешь, как это сложно в сравнении, потому что тебе уже не сложно это делать.
Я много раз предлагал всем желающим поучаствовать в написании сравнительных тестов, Z80/6502, M68K/65816. Желающих за много лет почему-то не нашлось ни разу. И думаю, это не сработает, потому что знающий только одну архитектуру будет продолжать придерживаться своих взглядов на эффективность, т.к. по прежнему не понимает другую сторону ('ах, ты добился такого же результата, но мне не нравится твой непонятный код, я считаю его некрасивым'), а у знающего обе вопросов про сравнение уже не возникает.
Самая главная проблема на SNES — откровенно неудачная система спрайтов. Если не сделать менеджер списка спрайтов грамотно, будут тормоза, наблюдаемые во многих играх. У большинства программистов тех лет просто не было опыта и времени разбираться, как решать эту проблему (но некоторые решали). Не выглядящие крутыми демки также показывают, что проблема решаема, а блог описывает, как именно. Я также пришёл к подобному решению, увидел изыскания этого товарища уже после этого.
Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
Попробую объяснить ещё раз. Эффект состоит из двух частей.
Первая часть 'рисует' залитый круг и трапецию в буфер в основном ОЗУ. Это самая обычная техника рисования полигона. В буфере для каждой строки всего два значения — самая левая точка и самая правая точка отрезка (xmin,xmax). Рисуем круг алгоритмом Брезенхема (потому что быстро): получаем координату точки, смотрим строку в буфере. Если точка нужна левее, чем левая — значим меняем в буфере на более левое значение. Если нужна правее, чем правая — тоже. Таким образом получается буфер ширины и смещения горизонтальных линий на экране, из которых состоит залитая фигура. Эта техника позволяет рисовать только выпуклые фигуры, то есть букву H ей не нарисовать (нужно два отрезка в пределах одной строки). Более сложное объяснение, если вдруг формулами понятнее, чем на пальцах: www.enlight.ru/faq3d/articles/24.htm
Вторая часть просто решает задачу быстрого вывода требуемых линий на экран, имея в распоряжении только железо SMD. С помощью изменения смещений слоя фона по HBlank мы можем вывести любую строку слоя фона в любую строку экрана. Заранее рисуем в слое фона все возможные ширины отрезков, какие нам понадобятся (т.е. от 1 до N пикселей). Теперь смотрим по буферу, подготовленному первой частью эффекта — надо отрезок шириной в три пикселя? Выводим третью строку слоя фона, где как раз и есть отрезок шириной в три пикселя. При этом смещаем её по горизонтали в нужное место экрана. Если у нас отрезок шириной в три пикселя не в одной строке экрана, а во многих — значит во все эти строки выводим строку фона с тремя пикселями.
В Clockwork Tortoise скорее всего были выходцы с демосцены, как в Zyrinx. Либо Jesper Kyd на них так повлиял.
У Nintendo с опытом было похуже. Вообще инженерная работа была проделана очень хорошая, в том плане, что огромная куча наворотов очень аккуратно и красиво организована в наборе регистров, и предусмотрены некоторые очень полезные и крутые фичи (HDMA, window mask, color math). Но там видимо сильно давил прошлый ограниченный опыт и идея сделать обратную совместимость, которую на полпути отбросили, а наследие осталось и сильно повредило результату: такие же карты тайлов, как на NES (ещё одна местная боль), крайне ограниченные спрайты и прочие странности. В общем-то даже 65816 и SPC700 скорее всего были выбраны по причине начального курса на обратную совместимость и простоту перестройки программистов на новую платформу (SPC700 тоже очень похож на 6502, но дурные официальные мнемоники маскируют этот факт).
Лично мне гораздо больше нравится писать под 65816, чем под 68000, никакой боли. Для понимания надо просто попробовать, трудно объяснить на словах, почему 3 РОН (на самом деле не сильно-то они общего назначения, по сути РОН всего один) не являются проблемой. Так только кажется, если смотреть издали, с других колоколен (8080 и 68K). Если искать проблемы в архитектуре 6502, это прежде всего ограниченность косвенной адресации, т.к. если надо иметь полностью динамический указатель для двух вещей одновременно (типа источник и приёмник в LZ-распаковщике), начинаются пляски с регистром Y (косвенная адресация всегда идёт по (ZP),y).
Вычислительная мощь однозначно сопоставимая, никаких сомнений у меня нет. Несопоставимо — это когда разница в разы, такого тут и близко нет. Реальная боль в заднице на SNES — вовсе не процессор, а видеоконтроллер, в особенности система спрайтов. Ладно битпланы, но ограничение на 1024 тайла на слой фона, только два формата спрайтов одновременно, только 512 тайлов на спрайты (!!!!), расположение тайлов спрайтов, разбросанные по двум спискам биты OAM, и много чего ещё — вот это реально очень напрягает.
Самый простой вариант диагонального скролла в SMB3 и Felix The Cat — вертикальная раскладка карт тайлов. По вертикали вообще ничего не дорисовывается, уровень всего два экрана в высоту (минус высота панельки снизу). По горизонтали дорисовывается прямо на экране (т.к. карта тайлов в ширину с экран). SMB3 просто не заморачивается по этому поводу, дорисовка видна визуально на краях экрана. Felix скрывает два вертикальных столбца на краях экрана, чтобы сделать дорисовку незаметной — слева аппаратной фичей выключения рендеринга в левом столбце, а справа столбцом чёрных спрайтов (т.к. аппаратной фичи для правого столбца не предусмотрено).
В других играх, где уровень выше двух экранов, стоит вопрос, скрывать вертикальную или горизонтальную дорисовку. Если выбрать горизонтальную раскладку экрана, легко скрыть горизонтальную дорисовку за экраном, но видна вертикальная. Её можно отсечь с помощью панельки или включения/гашения рендера позже начала/раньше конца кадра (обрезав высоту на 16 пикселей). Если не ошибаюсь, с гашением сделано в Jurassic Park. Можно сделать раскладку вертикальной, тогда вертикальная дорисовку получается скрыта, но видна горизонтальная. Её можно скрыть как в Felix, или оставить видимой как в SMB3 (нередко так и делали).
Часто не скрывали дорисовку просто потому что на старых ЭЛТ телевизорах края растра уходили за края видимой области экрана. Потому на всех ТВ-приставках времён ЭЛТ в гайдлайнах есть требования к safe area — к соблюдению области, в которой изображение будет гарантировано видимым. Т.е. за пределами safe area нельзя размещать критичную информацию типа очков или статуса. На NES это отступы примерно по 16 пикселей по вертикали и 8-16 по горизонтали.
Можно сделать горизонтальную раскладку, тогда область горизонтальной дорисовки скрыта, а вертикальной видна.
Звуковые чипы SN76489, TIA, AY-3-8910, POKEY появились довольно-таки задолго до IBM PC, в 1977-79 годах. Потому что игровым системам определённо был нужен звук, а PC в качестве игровой системы долго не рассматривался. Спикер PC предназначался для системных целей, и вероятно был сделан на канале таймера не из необходимости разгрузки процессора, а просто потому что таймер уже был и оставался лишний канал (другие каналы используются для действительно важных вещей — прерываний по таймеру и регенерации ОЗУ).
Огибающая в AY не для обогащения тембров. Она именно огибащая, как и ADSR — для задания изменения громкости во времени. Но в этих целях она оказалась слишком примитивной (в 1978 не особо понимали, что именно нужно). А богатые тембры из неё начали получать уже гораздо позже, лет через 12 после появления чипа — оказалось возможным запускать её на очень высокой частоте, таким образом, что периоды повторения сливались в тон (пилу или треугольник), а также смешивать с обычным каналом тона, что даёт вырожденный случай амплитудной модуляции (тон огибающей маскируется прямоугольным каналом).
В SID главная фишка — аналоговый фильтр, очень сильно окрашивающий звук. По сути приближение к архитектуре классических аналоговых синтезаторов. Аналогичную архитектуру, DCO и общий для всех каналов фильтр, имел, например, синтезатор Korg Poly 800 (1983).
В NES нет короткого буфера PCM. Там есть DPCM — однобитное кодирование 7-битного звука, в целях сжатия ценой сильных искажений, с аппаратным проигрывателем (читает память, декодирует, выводит в ЦАП, всем этим немного затормаживает процессор). Напрямую DPCM доступно 16 КБ адресного пространства ПЗУ, в которое можно включать банки посредством маппера (если есть). Зацикливать DPCM формально можно, но по самой природе кодирования нормального чистого цикла в сложных сэмплах не получится (будет сильно щёлкать переход), только если не специально сконструировать сэмпл буквально побитно (тогда можно вымучить, например, чистую пилу).
FM-синтез в чипах на самом деле PM, фазовая модуляция, близкая по сути вещь, но гораздо проще реализуемая. Т.к. это PM, именно вибрато, возможное в FM, толком не получить. Смысл этих видов синтеза в получении гармоник. Гармонический состав сигнала определяет его тембр, чем больше гармоник, тем сложнее и интереснее (реалистичнее в том числе) тембр. Две синусоиды при аддитивном синтезе были бы всего двумя гармониками, а при модуляции их получается намного больше.
К слову, на PS2 тоже применялась куча весьма интересных трюков. Например, в MGS (игра на последней картинке) есть блестящие, отражаюшие в себе всю обстановку полы. Как они сделаны: коридор скопирован и перевёрнут по линии пола, с пониженной детализацией, также перевёрнуты и отрисованы ниже линии пола модели персонажей, а сам пол сделан полупрозрачной текстурой, она затеняет нижнюю копию, и создаётся эффект отражения. И там много подобных маленьких трюков, в результате игра выглядит весьма круто для тех лет (версия на PS2 лучшая, во всех портах и римейках много чего урезано или испорчено) и при этом идёт на 60 FPS.