Ну эти демки особо крутыми не выглядят — много спрайтов в какой то момент и только.
Имхо всё же Маегава если и преувеличивал, то не сильно. Плоский прямолинейный проц с 32-битными операциями (пусть даже под капотом выполняющимися как 16-битные, но в системе команд команда одна и как бы 32-битная) и простые раскладки видеопамяти, включая таблицы спрайтов, очевидно должны сделать программирование сложных сцен и трюков на SMD проще. И даже если на SNES можно добиться таких же показателей — то это уже демосцена с выдавливанием соков, а не SMD — нет, просто сел и запрограммировал. Другое дело, что в SNES было еще много аппаратных интересностей просто отсутствующих в SMD.
Провёл небольшое исследование в том же эмуляторе Exodus.
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Не факт что и откуда первое пришло. Например выше тут упоминается команда Zyrinx — они пришли из демосцены и сделали игру Red Zone для Sega Mega Drive и настолько гордились тем что сделали, что прямо в титульных экранах игры вставили вот такую заметку:
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
«снимает ограничение на одновременное кол-во спрайтов в строке»
Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
Не не, эффект я понял сразу же. Я почему то забуксовал с наложением его на картину видеопамяти из эмулятора — смутно брезжило, что линии перескакивают и по вертикали, но уверенности не было. Теперь немного исправил пост, чтобы читателям тоже было понятнее.
Техника да, понятна, я её там же и описал по своему, непонятно как сформировалась полученная в эмуляторе картина сканлайнов — она не совсем соответствует картинке если переносить линии одну-за-одной как в первых рассмотренных эффектах. Наверное каждая линия может соответствовать сразу нескольким линиям в итоговом изображении из-за подмен по hblank, то есть рендер построчно перескакивает с линию на линию не только горизонтально, но и вертикально.
Я так понял, что еще немало странностей и сложностей росло корнями из-за того, что видеочип просто не успевал бы опрашивать видеопамять за HDraw если бы были включены все фичи. В результате видеорежимы разрослись как грибы после дождя — если какая то фича включалась, то начинали отваливаться другие. Единственный режим с четырьмя фонами, например, мог выводить их только в 4-цветном режиме, что было несерьезно для 16-битной консоли. Отрубили один слой — добавилось цветности двум слоям. И так далее. Битплейны и странная раскладка Mode 7 явно растут корнями из того, что видеочип раздельно мог опрашивать чёт/нечет видеопамяти как отдельные банки независимо. Но для программиста это был напряг.
Сега же сделали один видеорежим с максимумом сбалансированных возможностей и успокоились на этом. Согласен, что слабая цветность — весьма неудачный и самый наверное неудачный шаг для своего времени. Полупрозрачность может быть только еще была бы интересной фичей.
Да да, я буду про это завтра писать — все эти неудобные форматы и неудобные упаковки по разным массивам видеопамяти. Довольно напряжно. Sega конечно в целом на фоне SNES проста как две копейки и потому проще программируется. Но возможностей то реально из-за этого меньше. Впрочем два года форы у SNES делают это логичным.
У меня сложилось впечатление, что SNES без чипов дополнений на картриджах хуже подходит для динамического рендера. Его формат тайлов размазан по нескольким bit-plane-ам за исключением Mode 7, где другие проблемы, и тем более размазан, чем больше цветность тайлов.
У SMD же всегда всё 16-цветное и всегда тетрады бит плотно упакованы в один байт для пары соседних пикселей.
Проц на мой взгляд должен быть объективно быстрее и удобнее в программировании — семейство 6502 жутко неортогональное, 16-битный вариант использованный в SNES использует сегментацию памяти, 3 регистра общего назначения, постоянно надо лазить в память для получения второго аргумента арифметико-логической команды — из-за чего маппинг ПЗУ картриджа с ОЗУ представляет собой некоторую кашу для упрощения этих вещей…
В Sega 32-битная архитектура, плоская память, 16 высокоортогональных регистров общего назначения — я в принципе поверю, что даже если вычислительная мощь была сопоставимая, то всё равно программировать на этом WDC по сравнению с этим Motorola было «болью в заднице».
Опять таки, пару демок что видел на ютубе SMD vs SNES — у SMD динамический рендер обладал меньшей цветностью — мне показалось что как раз из-за размазки их по битплейнам. Хотя Mode 7 возможно можно раскрыть в более интересные эффекты, но там не применялось.
В дополнение к комментарию Shiru — посмотрел в эмуляторе на Super C — там используется горизонтальная раскладка A-B, поэтому по горизонтали проблем с прокруткой не могло быть. По вертикали же используется только тот факт, что некоторые телевизоры не отображают полоски сверху и снизу. В эмуляторе FCEUX можно либо выбрать регион PAL либо прямо в опциях NTSC указать отрисовку кадра с 0 до 239 строки (по умолчанию стоит 8 — 231, то есть скрыты по полоске тайлов сверху и снизу как в NTSC физически и происходило) и тогда рваные обновления тайлов сверху/снизу станут видны.
Эм. Если я правильно понял такой подход используется как раз во всяких 8-битных и 16-битных консолях при этом «дисплей листом» в них можно считать таблицу описания спрайтов и параметры фонов. То есть прямо перед формированием очередного сканлайна видеоизображения видеочип просматривает таблицу спрайтов, выделяет те из них которые попадают в данный сканлайн и формируют эту строку — отсюда ограничения на максимальное количество спрайтов в одной строке и тому подобное. Главный плюс этого для 8/16-бит заключается в крайне скромным требованиям к количеству видеопамяти — таблица спрайтов очень экономно их описывает. Недостаток — списки спрайтов сканируются каждый сканлайн заново — и как следствие число обращений к видеопамяти резко увеличивается по сравнению с блиттинговым подходом — видеочип как правило не оставляет центральному процессору шансов обратиться к видеопамяти в периоды HDraw, а иногда и на весь VDraw.
«Я правильно понимаю, что дисплей-лист выполняется блиттером (т.е. рисует 2-D битмапы в ОЗУ)?»
Не понял вопроса. Видеочип PS1 может выполнять разные команды поступающие в порт ввода — от выставления render-state-ов и блиттинга 2Д-изображений до растеризации треугольников с текстурированием и освещением. Рисует он в свою видеопамять как в единый большой фреймбуфер (в котором можно выделить окно рендера).
Про Nintendo DS не планировал, но у меня будут еще обстоятельные уроки по программированию его непосредственного предтечи — Game Boy Advance, там даже обратная совместимость. Собственно они взяли GBA, навесили на него дополнительную память, расширили функционал видеочипа до 3D, вставили вдвое более быстрый процессор, два дисплея и получился DS.
Почти сломал голову пытаясь понять почему фазовая модуляция в каких то случаях эквивалентна частотной, как говорит википедия. Но кажется наглядно понял — пока нарастает вычитание фазы это действительно как бы уменьшает частоту и наоборот когда слагаемое к фазе начинает нарастать.
Хаха! :) Действительно. Пересмотрел свои статьи, имеено да, эта ссылка упоминалась gamedev.ru/flame/forum/?id=226622&page=3#m32 в первой версии статье о мапперах денди. «Вот здесь: hypr.ru/blog/graphics/283.html есть отличная статья на тему того какими ухищрениями занимались создатели видеоигр для денди для этого дела. Частично там затронута и тема мапперов». В процессе реструктуризации она потерялась оттуда, ибо более уместна в статье про видеочип же.
Логика моих изысканий была в том, что бралось из консолей что постарше и что было в широком ходу. 3DO как исключение просто потому что хотелось понять где и как впервые вылезла 3D-графика в играх. Но про амиги есть ровно одна статья, которую сейчас выложу.
Всё, больше обзоров на консольные 32/64 бита у меня нет и вряд ли будут новые — этими двумя «золотыми» поколениями я лично свой интерес удовлетворил.
В следующих статьях вернусь к 16 битам — обзор на Sega Mega Drive и SNES, плюс некоторые трюки на первой и больная мозоль многих холиваров — сравнение того и другого «кто мощнее слон или кит». :)
Имхо всё же Маегава если и преувеличивал, то не сильно. Плоский прямолинейный проц с 32-битными операциями (пусть даже под капотом выполняющимися как 16-битные, но в системе команд команда одна и как бы 32-битная) и простые раскладки видеопамяти, включая таблицы спрайтов, очевидно должны сделать программирование сложных сцен и трюков на SMD проще. И даже если на SNES можно добиться таких же показателей — то это уже демосцена с выдавливанием соков, а не SMD — нет, просто сел и запрограммировал. Другое дело, что в SNES было еще много аппаратных интересностей просто отсутствующих в SMD.
И судя по всему кусок стены над дверью еще накрыт спрайтами, а не фонами. Три больших таких спрайта прямо над ней. В общем не без заморочек.
Что-то сюда картинка как то косячно загрузилась. Вот она же на фастпике: i91.fastpic.ru/big/2018/0925/be/6ce8e44d70e132d8ab446c2e3df679be.gif
А прикольно у них там.
На слое А рисуется потолок и «внешние углы». Они реально перерисовываются при движении под нужный угол.
На слое Б рисуется пол и «внутренние углы». Даже если там статичные тайлы они значит рассчитаны под любой ракурс который может дать игра. Возможно их истинное число просто невелико, учитывая что есть флаги отражения тайлов по осям.
Так или иначе углы действительно создаются на лету тайлами или их содержимым и разбиты разумно на оба фона как «внутренние» и «внешние».
Стоит сперва начало посмотреть до первых геймплейных моментов (не пропуская заставки), а потом перемотать на 7:40 и позырить на indoor-геймплей.
Ну не снимает, а скорее как то меняет — и еще надо смотреть как. Технически всё-равно надо успеть сформировать строку.
У спец-регистров в принципе bandwidth может как бы и не быть, то есть загрузив их в начале строки можно как бы «бесплатно» не пересекаясь в них лазить хоть каждый пиксель — на то они и регистры.
Но в любом случае победил в высокопроизводительных игровых системах окончательно блиттинг, причём в весь сюрфейс сразу и во много потоков, а роль видеоадаптера свелась к неспешному скармливанию в видеопорт уже готовых полностью пикселей.
Сега же сделали один видеорежим с максимумом сбалансированных возможностей и успокоились на этом. Согласен, что слабая цветность — весьма неудачный и самый наверное неудачный шаг для своего времени. Полупрозрачность может быть только еще была бы интересной фичей.
SMDдинамический рендер обладал меньшей цветностью..."имелся ввиду SNES
У SMD же всегда всё 16-цветное и всегда тетрады бит плотно упакованы в один байт для пары соседних пикселей.
Проц на мой взгляд должен быть объективно быстрее и удобнее в программировании — семейство 6502 жутко неортогональное, 16-битный вариант использованный в SNES использует сегментацию памяти, 3 регистра общего назначения, постоянно надо лазить в память для получения второго аргумента арифметико-логической команды — из-за чего маппинг ПЗУ картриджа с ОЗУ представляет собой некоторую кашу для упрощения этих вещей…
В Sega 32-битная архитектура, плоская память, 16 высокоортогональных регистров общего назначения — я в принципе поверю, что даже если вычислительная мощь была сопоставимая, то всё равно программировать на этом WDC по сравнению с этим Motorola было «болью в заднице».
Опять таки, пару демок что видел на ютубе SMD vs SNES — у SMD динамический рендер обладал меньшей цветностью — мне показалось что как раз из-за размазки их по битплейнам. Хотя Mode 7 возможно можно раскрыть в более интересные эффекты, но там не применялось.
Не понял вопроса. Видеочип PS1 может выполнять разные команды поступающие в порт ввода — от выставления render-state-ов и блиттинга 2Д-изображений до растеризации треугольников с текстурированием и освещением. Рисует он в свою видеопамять как в единый большой фреймбуфер (в котором можно выделить окно рендера).
Про Nintendo DS не планировал, но у меня будут еще обстоятельные уроки по программированию его непосредственного предтечи — Game Boy Advance, там даже обратная совместимость. Собственно они взяли GBA, навесили на него дополнительную память, расширили функционал видеочипа до 3D, вставили вдвое более быстрый процессор, два дисплея и получился DS.
В следующих статьях вернусь к 16 битам — обзор на Sega Mega Drive и SNES, плюс некоторые трюки на первой и больная мозоль многих холиваров — сравнение того и другого «кто мощнее слон или кит». :)