Практически «прикладное демостроение». С той лишь разницей, что сперва эти эффекты появились в играх и только потом перекочевали в демосцену. Независимый скролл каждого сканлайна на олдскул платформе был реализован в Coma Light 13, например, в 2012 году :).
Вероятно память буфера строки стоила бы слишком дорого в плане места на кристалле. В NES динамическая память OAM (описание спрайтов, X/Y/тайл/палитра) размером 2x256 байт занимает аж четверть кристалла PPU. Для варианта с буфером строки понадобилось бы ещё 2x256 байт, плюс возможно логика заняла бы сравнимо или больше, чем логика со сдвиговыми регистрами.
Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
«снимает ограничение на одновременное кол-во спрайтов в строке»
Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
Вот что мне неочевидно во многих приставках (и СМД в частности) — это отображение спрайтов из специальных регистров вместо того, чтоб рендерить все в пиксельный буфер. Я может уже надоел тут всем со своим буфером :), но когда я делал спрайтовый процессор, я понял, что лучше соорудить FSM, которая пройдется по объектам (спрайтам/тайлам), вычитает из памяти их графику и нарендерит ее в тру-колорный пиксельный массив сканлайна. Плюсы: снимает ограничение на одновременное кол-во спрайтов в строке, балансирует нагрузку на доступ в ОЗУ. У меня при том еще и ОЗУ 1-портовое и общее с другими подсистемами. У СМД ОЗУ 2-портовое, статический порт используется исключительно видеопроцессором. Зачем при этом мутить кашу из мультиплексиров спрайтовых регов, непонятно.
Не не, эффект я понял сразу же. Я почему то забуксовал с наложением его на картину видеопамяти из эмулятора — смутно брезжило, что линии перескакивают и по вертикали, но уверенности не было. Теперь немного исправил пост, чтобы читателям тоже было понятнее.
Вот прямо чувствую, что нет полного понимания эффекта, и моё объяснение не очень понятно. Конечно не получится без смещения по вертикали, суть эффекта в этом и стоит.
Попробую объяснить ещё раз. Эффект состоит из двух частей.
Первая часть 'рисует' залитый круг и трапецию в буфер в основном ОЗУ. Это самая обычная техника рисования полигона. В буфере для каждой строки всего два значения — самая левая точка и самая правая точка отрезка (xmin,xmax). Рисуем круг алгоритмом Брезенхема (потому что быстро): получаем координату точки, смотрим строку в буфере. Если точка нужна левее, чем левая — значим меняем в буфере на более левое значение. Если нужна правее, чем правая — тоже. Таким образом получается буфер ширины и смещения горизонтальных линий на экране, из которых состоит залитая фигура. Эта техника позволяет рисовать только выпуклые фигуры, то есть букву H ей не нарисовать (нужно два отрезка в пределах одной строки). Более сложное объяснение, если вдруг формулами понятнее, чем на пальцах: www.enlight.ru/faq3d/articles/24.htm
Вторая часть просто решает задачу быстрого вывода требуемых линий на экран, имея в распоряжении только железо SMD. С помощью изменения смещений слоя фона по HBlank мы можем вывести любую строку слоя фона в любую строку экрана. Заранее рисуем в слое фона все возможные ширины отрезков, какие нам понадобятся (т.е. от 1 до N пикселей). Теперь смотрим по буферу, подготовленному первой частью эффекта — надо отрезок шириной в три пикселя? Выводим третью строку слоя фона, где как раз и есть отрезок шириной в три пикселя. При этом смещаем её по горизонтали в нужное место экрана. Если у нас отрезок шириной в три пикселя не в одной строке экрана, а во многих — значит во все эти строки выводим строку фона с тремя пикселями.
Техника да, понятна, я её там же и описал по своему, непонятно как сформировалась полученная в эмуляторе картина сканлайнов — она не совсем соответствует картинке если переносить линии одну-за-одной как в первых рассмотренных эффектах. Наверное каждая линия может соответствовать сразу нескольким линиям в итоговом изображении из-за подмен по hblank, то есть рендер построчно перескакивает с линию на линию не только горизонтально, но и вертикально.
Я так понял, что еще немало странностей и сложностей росло корнями из-за того, что видеочип просто не успевал бы опрашивать видеопамять за HDraw если бы были включены все фичи. В результате видеорежимы разрослись как грибы после дождя — если какая то фича включалась, то начинали отваливаться другие. Единственный режим с четырьмя фонами, например, мог выводить их только в 4-цветном режиме, что было несерьезно для 16-битной консоли. Отрубили один слой — добавилось цветности двум слоям. И так далее. Битплейны и странная раскладка Mode 7 явно растут корнями из того, что видеочип раздельно мог опрашивать чёт/нечет видеопамяти как отдельные банки независимо. Но для программиста это был напряг.
Сега же сделали один видеорежим с максимумом сбалансированных возможностей и успокоились на этом. Согласен, что слабая цветность — весьма неудачный и самый наверное неудачный шаг для своего времени. Полупрозрачность может быть только еще была бы интересной фичей.
Эффект с прожектором в общем-то прост. Рисуем в слое графики фона как бы треугольник — сначала один пиксель, потом два, потом три, и так далее до полной ширины. Теперь с помощью прерывания по HBlank в каждой строке мы можем вывести в эту строку линию нужной ширины — просто выбираем нужное вертикальное смещение в слое фона для задания ширины линии и нужное горизонтальное смещение для её позиционирования по горизонтали. А имея возможность вывода линий любой ширины мы можем нарисовать на экране любую выпуклую фигуру, это самый обычный рендер полигона (буфер xmin-xmax, рисуем круги и линии алгоритмом Брезенхема).
В Clockwork Tortoise скорее всего были выходцы с демосцены, как в Zyrinx. Либо Jesper Kyd на них так повлиял.
У Sega был большой опыт с аркадами, они по сути просто немного урезали одну из своих аркадных платформ. К сожалению, они видимо слегка спешили, и упустили пару моментов, которые сделали бы железо ещё удачнее — в частности, 64-цветная палитра и 9-битный видео ЦАП очевидный просчёт, сделать чуть больше цветов было бы не сильно дороже, но явно лучше. И не сделали прерывание Z80 от таймера YM2612, по сути это всего один проводок, но он очень упростил бы жизнь.
У Nintendo с опытом было похуже. Вообще инженерная работа была проделана очень хорошая, в том плане, что огромная куча наворотов очень аккуратно и красиво организована в наборе регистров, и предусмотрены некоторые очень полезные и крутые фичи (HDMA, window mask, color math). Но там видимо сильно давил прошлый ограниченный опыт и идея сделать обратную совместимость, которую на полпути отбросили, а наследие осталось и сильно повредило результату: такие же карты тайлов, как на NES (ещё одна местная боль), крайне ограниченные спрайты и прочие странности. В общем-то даже 65816 и SPC700 скорее всего были выбраны по причине начального курса на обратную совместимость и простоту перестройки программистов на новую платформу (SPC700 тоже очень похож на 6502, но дурные официальные мнемоники маскируют этот факт).
Да да, я буду про это завтра писать — все эти неудобные форматы и неудобные упаковки по разным массивам видеопамяти. Довольно напряжно. Sega конечно в целом на фоне SNES проста как две копейки и потому проще программируется. Но возможностей то реально из-за этого меньше. Впрочем два года форы у SNES делают это логичным.
В GH нет рендера в видеопамять, там всюду готовые тайлы. Т.е. формат хранения графики с точки зрения переносимости этой игры непринципиален. Битпланы и плюс и минус, что-то рендерить сложнее, что-то проще (если надо всего 2-4 цвета, например). С практической точки зрения на SNES тоже всегда всё 16-цветное, фоны в 4 и 256 цветов используются очень редко.
Лично мне гораздо больше нравится писать под 65816, чем под 68000, никакой боли. Для понимания надо просто попробовать, трудно объяснить на словах, почему 3 РОН (на самом деле не сильно-то они общего назначения, по сути РОН всего один) не являются проблемой. Так только кажется, если смотреть издали, с других колоколен (8080 и 68K). Если искать проблемы в архитектуре 6502, это прежде всего ограниченность косвенной адресации, т.к. если надо иметь полностью динамический указатель для двух вещей одновременно (типа источник и приёмник в LZ-распаковщике), начинаются пляски с регистром Y (косвенная адресация всегда идёт по (ZP),y).
Вычислительная мощь однозначно сопоставимая, никаких сомнений у меня нет. Несопоставимо — это когда разница в разы, такого тут и близко нет. Реальная боль в заднице на SNES — вовсе не процессор, а видеоконтроллер, в особенности система спрайтов. Ладно битпланы, но ограничение на 1024 тайла на слой фона, только два формата спрайтов одновременно, только 512 тайлов на спрайты (!!!!), расположение тайлов спрайтов, разбросанные по двум спискам биты OAM, и много чего ещё — вот это реально очень напрягает.
У меня сложилось впечатление, что SNES без чипов дополнений на картриджах хуже подходит для динамического рендера. Его формат тайлов размазан по нескольким bit-plane-ам за исключением Mode 7, где другие проблемы, и тем более размазан, чем больше цветность тайлов.
У SMD же всегда всё 16-цветное и всегда тетрады бит плотно упакованы в один байт для пары соседних пикселей.
Проц на мой взгляд должен быть объективно быстрее и удобнее в программировании — семейство 6502 жутко неортогональное, 16-битный вариант использованный в SNES использует сегментацию памяти, 3 регистра общего назначения, постоянно надо лазить в память для получения второго аргумента арифметико-логической команды — из-за чего маппинг ПЗУ картриджа с ОЗУ представляет собой некоторую кашу для упрощения этих вещей…
В Sega 32-битная архитектура, плоская память, 16 высокоортогональных регистров общего назначения — я в принципе поверю, что даже если вычислительная мощь была сопоставимая, то всё равно программировать на этом WDC по сравнению с этим Motorola было «болью в заднице».
Опять таки, пару демок что видел на ютубе SMD vs SNES — у SMD динамический рендер обладал меньшей цветностью — мне показалось что как раз из-за размазки их по битплейнам. Хотя Mode 7 возможно можно раскрыть в более интересные эффекты, но там не применялось.
Маегава, конечно, погорячился. Что-что, а процессор является наименьшей проблемой на SNES, писать под него очень легко — это же чуть улучшенный 6502, едва ли можно придумать процессор проще. Да и про торможение боссов, это смотря как написать. На SNES сцене есть один человек (не могу сейчас вспомнить и найти, он постоянно менял ники), очень любит спорить именно на эту тему со случайными прохожими. Он написал демку Gunstar Heroes-подобной игры, там у него и составные объекты, и вращение — всё нормально, ничего не тормозит. Исходя из собственного опыта, я тоже уверен, что GH на SNES написать можно было без особых проблем.
В дополнение к комментарию Shiru — посмотрел в эмуляторе на Super C — там используется горизонтальная раскладка A-B, поэтому по горизонтали проблем с прокруткой не могло быть. По вертикали же используется только тот факт, что некоторые телевизоры не отображают полоски сверху и снизу. В эмуляторе FCEUX можно либо выбрать регион PAL либо прямо в опциях NTSC указать отрисовку кадра с 0 до 239 строки (по умолчанию стоит 8 — 231, то есть скрыты по полоске тайлов сверху и снизу как в NTSC физически и происходило) и тогда рваные обновления тайлов сверху/снизу станут видны.
Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
Попробую объяснить ещё раз. Эффект состоит из двух частей.
Первая часть 'рисует' залитый круг и трапецию в буфер в основном ОЗУ. Это самая обычная техника рисования полигона. В буфере для каждой строки всего два значения — самая левая точка и самая правая точка отрезка (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, и много чего ещё — вот это реально очень напрягает.
SMDдинамический рендер обладал меньшей цветностью..."имелся ввиду SNES
У SMD же всегда всё 16-цветное и всегда тетрады бит плотно упакованы в один байт для пары соседних пикселей.
Проц на мой взгляд должен быть объективно быстрее и удобнее в программировании — семейство 6502 жутко неортогональное, 16-битный вариант использованный в SNES использует сегментацию памяти, 3 регистра общего назначения, постоянно надо лазить в память для получения второго аргумента арифметико-логической команды — из-за чего маппинг ПЗУ картриджа с ОЗУ представляет собой некоторую кашу для упрощения этих вещей…
В Sega 32-битная архитектура, плоская память, 16 высокоортогональных регистров общего назначения — я в принципе поверю, что даже если вычислительная мощь была сопоставимая, то всё равно программировать на этом WDC по сравнению с этим Motorola было «болью в заднице».
Опять таки, пару демок что видел на ютубе SMD vs SNES — у SMD динамический рендер обладал меньшей цветностью — мне показалось что как раз из-за размазки их по битплейнам. Хотя Mode 7 возможно можно раскрыть в более интересные эффекты, но там не применялось.