Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
Вот интересно — каждый раз когда смотрю на игры с Sega, SNES, Amiga то, по сравнению с Atari XE/XL и C64, бросается в глаза, что спрайты субъективно выглядят очень отдельными от фона и, как правило, для анимации прорисовано очень мало кадров. Соответственно, возникает устойчивое впечатление, что делали на скорую руку.
Провёл небольшое исследование в том же эмуляторе Exodus.
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Вот indoor-эффект я до сих пор не смог раскусить до конца (аналогично ещё в Toy Story, но попроще). Т.е. я знаю, как это делается в общем случае, не на SMD, но если большинство эффектов из игр на SMD/SNES я повторить на них же готов и точно знаю, как это сделать, то этот — нет. Я бы стал делать честный рендер углов стен с подгрузкой графики в видеопамять, но они обходятся (довольно большим) набором статичных тайлов.
Не факт что и откуда первое пришло. Например выше тут упоминается команда Zyrinx — они пришли из демосцены и сделали игру Red Zone для Sega Mega Drive и настолько гордились тем что сделали, что прямо в титульных экранах игры вставили вот такую заметку:
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
Практически «прикладное демостроение». С той лишь разницей, что сперва эти эффекты появились в играх и только потом перекочевали в демосцену. Независимый скролл каждого сканлайна на олдскул платформе был реализован в 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 явно растут корнями из того, что видеочип раздельно мог опрашивать чёт/нечет видеопамяти как отдельные банки независимо. Но для программиста это был напряг.
Сега же сделали один видеорежим с максимумом сбалансированных возможностей и успокоились на этом. Согласен, что слабая цветность — весьма неудачный и самый наверное неудачный шаг для своего времени. Полупрозрачность может быть только еще была бы интересной фичей.
Демка явно предшественница двух последующих, которые я не могу найти. В одной была графика прямо из GH, в другой очень стрёмная оригинальная графика с какой-то девочкой-роботом. В целом, можно видеть, что ещё 8 лет назад у него без проблем получалось сделать огромную кучу объектов и составные анимации без замедлений.
И судя по всему кусок стены над дверью еще накрыт спрайтами, а не фонами. Три больших таких спрайта прямо над ней. В общем не без заморочек.
Что-то сюда картинка как то косячно загрузилась. Вот она же на фастпике: i91.fastpic.ru/big/2018/0925/be/6ce8e44d70e132d8ab446c2e3df679be.gif
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
Пиксельный буфер в импортных приставках мне не припоминается нигде. Впервые я увидел эту идею в V2Z80 (который задолго до V6Z80P), который из ранних 2000-х, и она показалась мне очевидной и логичной. Чуть позже узнал, что и в советском игровом автомате ТИА-МЦ-1 ~1988 года спрайты тоже сделаны с буфером строки, там даже три буфера 256x4 (16-цветные спрайты). А потом уже стал вникать в эти детали по популярным приставкам, и удивился, что там сделано совершенно иначе.
Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
Попробую объяснить ещё раз. Эффект состоит из двух частей.
Первая часть 'рисует' залитый круг и трапецию в буфер в основном ОЗУ. Это самая обычная техника рисования полигона. В буфере для каждой строки всего два значения — самая левая точка и самая правая точка отрезка (xmin,xmax). Рисуем круг алгоритмом Брезенхема (потому что быстро): получаем координату точки, смотрим строку в буфере. Если точка нужна левее, чем левая — значим меняем в буфере на более левое значение. Если нужна правее, чем правая — тоже. Таким образом получается буфер ширины и смещения горизонтальных линий на экране, из которых состоит залитая фигура. Эта техника позволяет рисовать только выпуклые фигуры, то есть букву H ей не нарисовать (нужно два отрезка в пределах одной строки). Более сложное объяснение, если вдруг формулами понятнее, чем на пальцах: www.enlight.ru/faq3d/articles/24.htm
Вторая часть просто решает задачу быстрого вывода требуемых линий на экран, имея в распоряжении только железо SMD. С помощью изменения смещений слоя фона по HBlank мы можем вывести любую строку слоя фона в любую строку экрана. Заранее рисуем в слое фона все возможные ширины отрезков, какие нам понадобятся (т.е. от 1 до N пикселей). Теперь смотрим по буферу, подготовленному первой частью эффекта — надо отрезок шириной в три пикселя? Выводим третью строку слоя фона, где как раз и есть отрезок шириной в три пикселя. При этом смещаем её по горизонтали в нужное место экрана. Если у нас отрезок шириной в три пикселя не в одной строке экрана, а во многих — значит во все эти строки выводим строку фона с тремя пикселями.
Сега же сделали один видеорежим с максимумом сбалансированных возможностей и успокоились на этом. Согласен, что слабая цветность — весьма неудачный и самый наверное неудачный шаг для своего времени. Полупрозрачность может быть только еще была бы интересной фичей.