На фоне всеобщего шума вокруг стримерши Карины (черт, не думал, что когда-то заинтересуюсь этой личностью) на Furfur был написан материал, разбирающий как ее саму, так и всю ситуацию в целом: http://www.furfur.me/furfur/freedom/how ... to-me-nice. Материал объемный и я ввиду своей занятости только сегодня взялся прочитать. Что хочу сказать, так это то, что обсуждать его особого желания нет, но прочитать посоветую. А еще напомню ситуацию с Mr. Freeman, где оказалось, что это не один человек, а целая команда со своими целями.
К статье к Карине предлагается почитать схожий разбор ситуации по GamerGate: http://www.furfur.me/furfur/culture/cul ... -gamergate. Думаю, что история с GamerGate более знакома рядовым геймерам, чем стримерша Карина. Последствия этого скандала тянутся до сих пор и цепляют всех без разбору геймеров. Например пятая точка одного из персонажей (Трейсер, если не ошибаюсь) Overwatch или кадры с нового Street Fighters. И таких случаев можно накопать больше, значительно больше. Не знаю, что нас ждет через несколько лет, но нынешние обстоятельства несколько тревожны. Конечно понятно, что игры стали более массовым продуктом, как фильмы и музыка, но накидываться на них, пытаясь выпрямить под свой лад мне кажется неправильным и поступком слабых.
Это далеко не единственные статьи, которые подходят к игровому миру с разных сторон, поэтому, если кому что-то подобное попадется, накидайте ссылочек, пожалуйста.
Вообще не понимаю хайпа вокруг этой личности, все это выглядит так убого и стремно, или просто у задротов заиграли гормоны от увиденной самки, разделяющей их интересы, "Колян, слыхал, телочка играет в видеоигры, это ведь так круто, нужно обязательно её смотреть и обсуждать везде где только можно, а еще она материться, это ведь вообще круто, так сломать стереотипы еще никому в голову не приходило, гы-гы-гы, пойду еще задоначу ей пару сотен, вот тогда она точно заметит меня, мы поженимся и будем жить долго и счастливо".
Lord Zedd В статье как раз психологи и др. душевные (духовные?) работники хорошо развернули эту тему, не оставив вопросов.
На самом деле прикол Карины в том, что она ярко и порой наигранно реагирует на все оскарбления в свою сторону. А народу это нравится (почему в статье описали). Но в любом случае за этой маской кроется отличная бизнес модель - это все не просто так.
EmgrtE Даже обсуждать это не хочу, ибо данный феномен для меня настолько туп, что у меня на счет Карины, просто нету цензурных слов и дело даже не в самой Карине, т.к. девочка тупо делает бабки, а в культе которой вокруг неё развели, такой шум подняли из ничего, и продолжают всюду продвигать её в массы...Вообще я бы Карину сравнил с передачей Дом-2, все знают насколько это тупо и убого, но тем не менее подняли такую шумиху на пустом месте, собрав армии фанатов, не иначе это одно из самых лучших шоу в истории.
Очередная попытка разобраться, почему же фильмы по играм в осномном полное гуано. Для любителей почитать.
Болезнь экранизации видеоигр
Цитата:
Мы с вами живем в интересную эпоху «злободневных» тем. Практически каждое событие с появлением интернета стало общедоступным и к нему легко приплести свое мнение. Но одна тема, особо деликатная для геймеров, не дает мне покоя более остальных. И нет, речь не о цензуре и не о «распиливании» игр на DLC, но про не менее ужасное событие в жизни каждого фаната игровой франшизы – ее экранизацию. Насколько грустно это не прозвучит, но ожидаемое кино по мотивам наших любимых и дорогих сердцу франчайзов, обычно на выходе имеет дурной запашёк. В подтверждении этому можно привести разумный довод, что единственной экранизацией по серии игр, которой удалось перевалить за третью часть, стала вариация Пола Андерсона на Resident Evil. И опять-таки, она на плаву далеко не за счет качества или бережного отношения автора к первоисточнику, а потому что хорошо идет под попкорн и стоит сравнительно недорого, чтобы окупаться. С тех пор, как игры массово захватили пальму первенства среди домашних развлечений, некоторым толстосумам киноиндустрии в голову пришла отличная идея, как можно наварить еще больше, затратив при этом еще меньше. Так появилось прекрасное стремление подарить нам, игрокам, новый опыт от наши любимых игр или, как это звучит на самом деле, еще подоить «денежную коровку». Но почему в итоге получается достаточно паршиво, ведь, казалось бы, все необходимое уже лежит на виду, просто нужно аккуратно перенести это на экран? Давайте попробуем окунуться в это поглубже. Практика «экранизировать» игры пошла достаточно давно и в связи с ограничениями, которые налагались на игры того времени, выбирать приходилось из достаточно странных первоисточников. Так Nintendo подарила нам усатого водопроводчика, о приключениях которого киноделы вскоре сварганили отвратительную экранизацию Super Mario Bros, судя по качеству которой, можно смело говорить, что это было актом анти-рекламного теракта. Сюда же можно отнести экранизацию файтинга Street Fighter, говоря о которой при фанатах, последние предпочитают делать вид, будто слышат о ней впервые. И не зря (если о нем не думать, может оно исчезнет?) Прошло достаточно много времени, с тех пор как машина киноадаптирования была запущена и, казалось бы, что должен был хоть кто-то за это время научиться на ошибках и сделать кино хоть раз правильно! Однако на дворе уже 2017, а нам и сегодня приходится довольствоваться экранизацией игры Mortal Kombat, которая опять-таки носит статус «сносно» и с течением времени лучше не становится. В 2005 вышел фильм по игре Doom, и он также, как и остальные, упомянутые выше картины, не дотягивал даже до нижней границы понятия «хорошо». Единственное, чем он запоминался, – это лысина Дуэйна «скалы» Джонсона и пара минут экшена от первого лица. Но, возможно, причина как раз и кроется в том, что экранизировать в этих играх нечего? Что если всеми неудачами киноадаптации обязаны неподходящему первоисточнику? Сюжеты, как о братьях водопроводчиках с принцессой в «другом» замке, так и о уличных бойцах с планом по захвату мира, слишком уж «просты» для больших экранов. Джон Кармак так и вовсе говорил, что Сюжет в игре, как сюжет в порно фильме. Он должен быть, но совершенно не важен. И тогда становится совершенно неудивительно, что если на экране должен быть двухчасовой фильм, то авторам приходится добавлять множество «отсебятины», дабы сделать это отличным по смысловой нагрузке от уже упомянутого «порно», но тогда возникает риск, что общая идея уйдет слишком далеко от первоисточника. В кино, в отличие от игры, не удастся погрузить зрителя в сам процесс, так как он просто на просто отсутствует, а показывать полтора часа имитацию игрового действа и прочих радостей геимплея… Всегда есть трансформеры, на которых у рядового зрителя челюсть от зевка сводит уже к середине. А ведь там хоть диалоги есть! Но, резонно будет возразить, что есть игры, в которых сюжету уделено довольно много внимания и его вполне можно экранизировать в отрыве от игрового процесса. Да что там, есть игры, где процесс вовсе вызывает раздражение, а единственная причина почему вы не можете выключить игру – отличный сюжет и постановка. Да, такое тоже встречается. Последнее время особенно много проектов, которые не до конца являются полноценными играми, а многое заимствуют из кино. Проблема лишь в том, что такие «игры» вполне себе самодостаточны. Кино – это не просто покадровая пересъемка, но также и адаптация, переосмысление. На худой конец – свое виденье исходного материала. В фильмах это необходимо, потому такие умело рассказанные истории, как the The Last of Us, в киноверсии, по заявлению, будут отличаться, чуть ли не на 60 процентов. Возможно, мы и рады были бы увидеть знакомых героев и знакомые ситуации еще раз, но вряд ли это вызовет у нас те же эмоции, что были при знакомстве с игрой и сможет нас заинтересовать так же сильно. По этой причине я совсем не склонен считать, что экранизация должна следовать за первоисточником след в след. Но есть и то, что сохранить нужно обязательно. То, без чего адаптация теряется и становится уже даже не отсылкой к оригиналу, а просто вольным и даже вульгарным произведением, паразитирующим на имени первоисточника. Так, например, можно вспомнить экранизацию Макса Пейна. Пусть фильм получился и не таким плохим, но оценить его по достоинству могли лишь люди с игрой незнакомые. Слишком много в него добавили своего, слишком другого подхода в нем придерживались авторы, от чего ни сам Макс, ни место действия, ни даже нуарный стиль не походили на себя. За другой пример даже обосновывать не нужно. Это экранизация Resident Evil от, опять-таки, Пола Андерсона. В ней так много отсебятины и так мало от оригинала, что единственное родство за все вышедшие фильмы — это перекликающиеся имена и зомби тематика, все остальное, по типу пересъемок сцен из игры, скорее похоже на фан-сервис, чем на дань уважения оригиналу. Однако полностью отчаиваться ненужно. Есть случаи, когда при переносе и адаптации удается сохранить самое важное. Таким примером может послужить туманный фильм о не менее туманном городе Silent Hill’е. Несмотря на то, что сюжет является компиляцией из нескольких источников, хоть и дополняется деталями, которых не было, а некоторые монстры заимствованы из других частей, основное действующее лицо, а именно сам город-призрак, передан так, как это должно быть. Фильм не стремится переврать все и вывернуть на изнанку, но в достаточной степени отличается, что бы его было интересно смотреть и людям игру прошедшим. В этом случае и отсылки смотрятся уместными, а основные черты узнаются сразу. Так выходит по разным причинам, одной из которых является то, что в случае с Max Payne’ом режиссёр открыто говорил, что не знаком с первоисточником и в игры вообще играть не любит. Такой подход просто не может бесследно пройти по проекту в основе которого лежит игра, которую режиссер в глаза видеть не собирается. Но ни это одно при адаптации может сыграть ключевую роль. Не менее губительным может оказаться стремление привлечь к продукту новую аудиторию. В кино ходят далеко не всегда те же люди, что играют в игры, а потому для зрителя часто приходится многое разжёвывать с самого начал. Проблема в том, что адаптируются как правило не штучные игры, а серии, вобравшие в себя большую и длинную историю, рассказываемую на протяжении долгого времени. Передать основные особенности Лары Крофт или Принца Персии, при этом раскрыв персонажей и не скомкав события, которых в игре часов на десять, задача явно не из простых. А теперь подумайте, какой ад ждал ответственных за сюжет Warcraft, у которого лор на три номерных части и одну ММО… Понятно, что в таком случае возникают сюжетные дыры, отхождения от оригинала, упрощения, а что-то выглядит просто не на своем месте, но этому способствует и другая деталь – субъективное восприятие. Не зря Silent Hill, будучи открытым для трактовок, является для каждого метафорой на что-то личное, свое. И пусть не все произведения так открыты для доводов и интерпретаций, при попытках ужать материал или изменить в угоду истории, каждый сделает акцент на важности разных черт и элементов. Потому не удивительно, что в итоге получается не совсем то, что вы ожидали увидеть, но основной причиной расстройства служит факт, что вы уже знакомы с первоисточником и более критично воспринимаете ситуацию, при которой ответственный за адаптацию человек делает неправильные, по вашему мнению, акценты. Это свойственно не только играм, но и вечному спору про «что лучше»: книга или кино, старая игра или новая и так далее. Вы полюбили первоисточник за какие-то особенности и вам больно видеть, что другой человек восхваляет в ней нечто другое, менее значимое, по-вашему субъективному мнению. И еще одна проблема экранизации, это то, что в игре основной элемент все же геймплей. Из-за этого, в той или иной мере, но вы проецируете себя на персонажа, хотя бы тем, что сами решаете куда ему идти, когда прыгать, а когда тыкаться головой в стену. В фильме вы видите полюбившегося персонажа, но которым управляет другой человек и в вас возникает подозрение, что это обман. Что это уже не тот герой, с которым вы сроднились, а лишь пародия на него. Наверно, в детстве у каждого было, (когда еще ходить в гости считалось нормой) что стоя за плечом играющего друга, вы прямо из кожи вон лезли, потому что он делал все неправильно! А теперь просто помножьте это на полтора часа хронометража… Для заключения я отвел, возможно, самое плохое, что может произойти с киноадаптацией. Это превращение ее в рекламу! Фильмы — это не только вид искусства, но и большой трейлер, который завлекает новых людей, а потому часто он наплевательски относится к своей фан-базе в угоду новых зрителей. Если фильм постигает такая участь, то его задача просто окупиться, и никто не станет вкладывать в него больше усилий, чем те, что смогут вернуться в виде зеленых бумажек, а еще раз повторюсь, не все, кто ходят в кино – играют в игры. Так бывают ли удачные экранизации игр? Как я уже говорил – да. Пусть у таких фильмов не самые высокие рейтинги и не самые лучшие отзывы критиков, все же это не удивительно. Кино имеет свои критерии оценки, которые далеко не всегда подходят для игр. Что хорошо для игры, не всегда будет так же хорошо для кино, потому хорошая адаптация может не всегда быть хорошим фильмом и ровно наоборот, хорошее кино, может вызвать порыв ненависти у фанатов игры. Пока есть такие примеры как Silent Hill, где видно попытку передать дух и антураж туманного города, люди знакомые с серией будут радоваться, а киноманы могут придраться к фильму, например, за неубедительную игру главной актрисы. Еще к удачным экранизациям можно отнести фильм Warcraft. В нем прекрасно сочетается внимательное отношение к истории и деталям, масса усилий по адаптации исходного материала, прекрасный и узнаваемый визуал, а также рваный монтаж, сбивчивый ритм повествования и изменения в исходном лоре. Совсем неудивительно, что при попытке рассказать историю и для знакомых с серией зрителей, и для зрителей новоприбывших возникли ситуации, когда недовольны остались обе стороны. И пусть его нельзя назвать фильмом на века, давайте честно признаемся в одном — это было достаточно волшебно, эпично и узнаваемо, чтобы, и выйдя из зала, мы не хотели засорить ленту негодующими отзывами. А знаете, что лучше всего вписывается в данную теорию? Неожиданно удачная экранизация игры Postal. Да, говорить о кино и Уве Болле в одном предложении, не только опасно для психики, но, как убедились некоторые критики, опасно еще и для здоровья. Однако, маэстро уже проложил себе путь к славе через неуважение, как к киноискусству, так и к играм. Но с «чуваком» из Postal, ситуация совсем обратная. Никто не станет спорить, что это ужасный фильм, с неправильной подачей, неправильной режиссёрской работой, рваными повествованием и слишком черным, слишком пошлым и слишком расистским юмором. Но также, мало кто станет оспаривать, что это отлично передает дух игры! За это и любят Postal, а потому такое варварское отношение к кинематографу, отлично передает мировоззрение игры. И раз так, то выходит, что хороший фильм по игре не обязан быть хорошим фильмом. Он просто должен быть достаточно узнаваемым и уважительно относиться к оригиналу, что бы мы могли получить от него удовольствие. Это под силу, как качественным лентам, так и достаточно средним. Потому я считаю уместным задать другой вопрос: а нужны ли в таком случае эти фильмы? В наше время популярны фильмы по комиксам, которые раньше считались достаточно неперспективными. Есть фильмы по книгам, хотя споры о том, что лучше не утихают уже многие года. Так что должно мешать существованию фильмов по играм? В наше время принято задействовать все виды медиа, для удержания интереса. Ежегодно выходят тысячи игр, книг, артбуков, саундтреков, а фильмы – это просто еще один элемент этой системы. Сомневаться в нужности этих фильмов не приходится, у них уже есть готовая аудитория, такой проект будет работать в две стороны, как привлекая к фильму внимание игроков, так и заманивая в игру людей довольных фильмом, но при этом нужно всегда помнить о двух проблемах: наплевательском отношении, при котором ленте уделяют так мало сил, что она попросту не может понравиться никакой из смотрящих сторон и то, что при общей тенденции таких фильмов может стать слишком много. Уже сейчас вышли фильмы по Assassins Creed, Tomb Raider, Hitman, Doom, а готовятся еще больше: Uncharted, Last of Us, перезапуск Лары Крофт, приключения тайного агента Сема Фишера и даже огромная серия фильмов по вселенной Call of Duty! При таком обилии скоро эти фильмы не станут привлекать нас так сильно и перестанут быть чем-то особенным. Их будет много, потому они просто утратят тот шарм, который порой заставляет пойти на них, даже если в душе мы понимаем, что увидим нечто отвратительное. Но негоже заканчивать беседу на грустной ноте. Всегда есть вероятность, что случится правило «1000 обезьянок и сборника произведений Шекспира», а потому возможно что-то из запланированного удивит и порадует нас своим качественным подходом, как в виде фильма, так и в бережном отношении к оригиналу. А пока для тех, кто слишком болезненно относится к теме «отхождения от канона» есть пусть и технически не совсем фильмы, но такие ленты как Dead Space: Downfall, Resident Evil: Degeneration и Final Fantasy, которые рассчитаны на непосредственно игровую аудиторию. Они продолжают и раскрывают вселенную этих игр, являются прямым дополнением для первоисточников и следуют тем канонам, что были заложены играми, предшествовавшими им.
Довольно интересная статья, и опять-таки про Naughty Dog, хотя я недавно постил про неё и здесь, и здесь.
В общих чертах - то же самое, но немного о другом.
Началось с того, что я увидел это обсуждение про Crash Bandicoot: STNICCC2000 3DO by optimus И мне стало интересно, а сколько, собственно, полигонов в Крэше? Стал гуглить и нашел эту статью, где всё как раз подробно расписано:
К сожалению, статья очень велика и не влезает даже в два форумных поста (ограничение 60000 символов).
Как они утверждают, сам Crash Bandicoot состоял из 512 полигонов (моделька). А на игровой сцене уровня всего использовалось 1800 полигонов.
Для 3DO это, конечно, много. Сама приставка могла выдать пару-тройку тысяч, но и то с хитростями - отсечением неотображаемых поверхностей и т.д. Это nikk разжевывал в теме "3DO SDK", когда делал простейший тестовый трёхмерный движок для консоли.
Вложение
37.jpg
Ну и вообще - в статье много интересного. Как вышел Mario 64, как Сигэру Миямото на E3 играл в Crash Bandicoot и т.д. Большая статья, но стоит прочитать.
У вас нет необходимых прав для просмотра вложений в этом сообщении.
Обзор графической архитектуры 3DO Interactive Multiplayer
Блог им. aa-dav
3DO — консоль опередившая своё время. У нас она слабо известна да и конкурентную борьбу она быстро проиграла. Тем не менее замечательна она тем, что вышла первой в пятом поколении — первой посягнула на рубежи полноценного 3D. Однако при этом это самое 3D в ней из–за молодости индустрии было реализовано весьма кривобоким образом, ныне вымершим. Так же интересна консоль была еще несколькими моментами. Подробно можно прочитать на вики. Но я и тут сделаю краткий очерк.
Вложение
0bfeb226da.jpg
Во первых — правообладатель консоли, The 3DO Company, не имел собственных мощностей и связей, поэтому разработав спецификацию железа предложил всем желающим производить его за лицензионные отчисления. Из-за такого подхода производители железа не могли продавать консоль себе в убыток, чтобы отбивать прибыль на продаже игр — поэтому и цены на консоль получились кусачими и она быстро покинула рынок. Всего было три активных производителя консоли, из которых Panasonic стал наиболее часто с ней ассоциироваться, поэтому её нередко неправильно называют Panasonic 3DO. На самом деле Panasonic 3DO — это лишь конкретная и только одна из реализаций общей технологической спецификации 3DO Interactive Multiplayer.
Вышла первая консоль в США в сентябре 1993 года — то есть за пару месяцев до релиза Doom 1. Так что окунёмся на несколько минут в графические реалии 3DO, посмотрим что это был за зверь.
ЦП
Центральным процессором (ЦП) в 3DO был 32–битный ARM (ядро ARM60, семейство ARM6, архитектура ARMv3) на частоте 12,5 МГц. Это еще без кэша и многостадийных конвейеров. Для сравнения говорится, например, что он обладает эквивалентной производительностью Motorola 68k на частоте 25 МГц (конкретно — 68030, то есть уже с 32–битным АЛУ). Система обладает 2 Мб основной RAM и 1 Мб Video RAM (VRAM). Как минимум VRAM доступна одновременно и ЦП и видеочипу. Но вообще в документации как то вообще не делается упора на ограничения где должны лежать данные для Cel Engine, так что складывается ощущение, что VRAM привилегированна только по операциям SPORTS. SPORTS это особое устройство и контроллер VRAM которое позволяет очень быстро поблочно её копировать или заполнять одинаковым значением. SPORTS работает только в пределах одной плашки VRAM в 1 Мб, если бы выходили расширения системы с несколькими мегабайтами VRAM, то документация чётко обозначает, что функции SPORTS способны копировать регионы только внутри блоков по 1 Мб. Вообще, судя по документации, система явно проектировалась на вырост, много упоминаний, что та или иная программная функция в библиотеках еще не реализована — но когда–нибудь будет. А так же как раз отсылок к потенциальным разным конфигурациям и объёмам памяти (которых не случилось). Программировать предлагается в рамках многозадачной ОС называемой Portfolio. В консоли кроме всего прочего есть 1 Мб ROM (и он далеко не пустой), так что видимо часть её сидит в там. Так как в основном я читал документацию именно из Portfolio SDK ( скачать эту документацию можно тут: develop3do.narod.ru/index.files/devdocs.htm ), то сведений о том как именно устроено железо, его порты ввода–вывода и сообщение между компонентами в дальнейшем почти не будет. Только то, что важно с точки зрения SDK. Однако, кое какие любопытные особенности и это нам прекрасно показывает.
Дисплей
Видеобуфер для вывода на экран может иметь размеры 320x240 или 320x480 16–битных пикселя. Однако видеосигнал всегда выходит в разрешении 640x480 и цветности 8:8:8, причём каждый пиксель может отличаться от соседних. Так получается благодаря двум вещам:
1) Сложная система цветности: 16–битные пиксели привычно раскладываются на три 5–битных компоненты R, G и B, но эти компоненты в 3DO воспринимаются не сразу как интенсивности соответствующих каналов цвета, а как индексы из трёх независимых массивов из 32–ух 8–битных элементов из этих интенсивностей. То есть это HiColor который индексирует покомпонентно TrueColor :) Всё еще осложняется тем, что если все 3 цветовых компоненты равны 0, то пиксель обрабатывается особым образом — его цвет берется из дополнительного 33–го слота этих же цветовых таблиц, а сам он опционально может стать прозрачным для оверлея заднего изображения на экране — это фича могла пригодится при наложении изображения на телевизионные вещи в телевизионных приставках, что заранее предусматривалось. Причём этих таблиц RGB–интенсивностей в системе две — одна зашитая и неизменяемая просто перечисляет интенсивности с таким шагом чтобы линейно отобразить 5–битные индексы в 8–битные цвета, таким образом реализуя обычный HiColor. Но есть еще другая — пользовательская, программируемая, причём возможности видеосистемы позволяют полностью переопределять её перед каждым сканлайном изображения, таким образом сильно раздвигая цветовую комбинаторику аппарата. Плюс всё это еще осложняется тем, что неиспользованный бит в 16–битном пикселе (оставшийся после 5+5+5 индексов) может быть определен как раз под селектор палитры, раздвигая таким образом дипазон одновременно отображаемых цветов до 65536 штук и без манипуляций со сканлайнами.
2) Повышенная чёткость посредством «cornerweights» Неиспользованный бит в пикселе таки не давал покоя и была придумана еще техника cornerweights — каждый из 320x240 логических пикселей разбивался по вертикали и горизонтали на 4 выходных пикселя–соседа (с итоговым разрешением 640x480) и один из этих соседей помечался как «основной». Основной пиксель отображался ровно цветом своего логического пикселя. А вот цвета его трёх соседей интерполировались с соседними логическими пикселями — причём сложным образом, чем ближе к ним были «основные» пиксели логических соседей, тем сильнее они оказывали влияния на итоговый цвет. Для указания какой сосед из четырёх является основным нужно два бита, а «халявный» в пикселе был только один. Поэтому для полновесного «cornerweight» режима еще один бит отбирался у синей компоненты, она таким образом становилась 4–битной. Кроме того возможны были варианты — значение одного из бит для cornerweight могло быть задано глобально как константа и тогда только второй бит брался из пикселя. В этом случае все цвета сохраняли свою битность, но «повышенная четкость» теряла в вариативности.
Суммируя вышесказанное можно наконец то описать видеорежимы 3DO — логическое разрешение экрана было 320x240 или 320x480 пикселей, но итоговая чёткость и цветность картинки могла разнообразится одним из четырёх вариантов: 1) Формат пикселя Wrrrrrgggggbbbbb — один бит задействован под cornerweight 2) Формат пикселя WrrrrrgggggbbbbW — два бита задействованы под полноценный cornerweight, синий канал лишён бита 3) Формат пикселя Prrrrrgggggbbbbb — один бит задействован под селектор палитры 4) Формат пикселя PrrrrrgggggbbbbW — один бит под cornerweight, еще один под селектор палитры и синий канал лишён бита
Лично мне кажется, что вся это возня и переусложнение сделаны совершенно напрасно. Тем более, что сама аппаратура консоли интерполирует цвета рассчитывая как раз на линейное соответствие индексов интенсивностям, то есть серьезные заигрывания с палитрами заранее обречены на отказ от каких то частей пайплайна. Учитывая, что консоль вышла за три месяца до выхода легендарного Doom 1 (который, кстати, попадёт на консоль только тремя годами позднее и в ужасном качестве) в который все играли высунув язык и в 256–цветной палитре, то все эти потуги выдоить из «халявного» бита то больше цветности в HiColor, то какую то повышенную чёткость контуров — выглядят борьбой с ветряными мельницами.
Дисплейные списки
Еще одной «заморочкой» 3DO является то, что при выводе битмапа фреймбуфера на экран палитра и параметры повышенной чёткости могут меняться в каждой строке (сканлайне) изображения. Начальная установка таковых параметров (для первого сканлайна) и далее их смена производится через дисплейные списки (VDL — Video Display List) — это структуры переменной длины от 5 до 38 слов (32–битных) в памяти, которые задают эти разнообразные параметры, количество сканлайнов которое данный VDL будет действовать и (опционально) указатель на следующий VDL к которому надо перейти после них. VDL может содержать установку следующих параметров дисплея: — адрес в видеопамяти, где находятся пиксели текущей строки (сканлайна) для вывода на экран — параметры формата пикселя и значений по умолчанию для бит палитр и cornerweight — содержимое таблицы пользовательской палитры (для задания всей таблицы палитры нужны 33 слова, что и диктует большую часть максимального размера VDL) — размер текущего VDL (4 слова — минимум заголовка, плюс от 1 до 34 переменной части) — количество сканлайнов после которых нужно переходить к следующему VDL (0, если этого делать больше не нужно)
В первом VDL обязательно должен быть задан адрес текущей строки пикселей в памяти, которую надо рисовать, в следующих же это не обязательно — за отсутствием смены будет рисоваться один большой фреймбуфер, адрес строки автоматически сдвигается с каждым сканлайном. В принципе, если параметры дисплея не меняются в кадре, то одного затравочного VDL может быть достаточно — в нём надо будет выставить количество сканлайнов в 240 или 0. В самом сложном случае можно сделать 240 разных VDL, связав их в список, выставив разную палитру и параметры отображения (и даже нацелить каждый на собственный сканлайн в памяти). Однако больше смысла имеет организация с помощью VDL сложных схем двойной буферизации — например в видеопамяти можно завести три битмапа в 200, 200 и 40 строк. В последнем будет хранится редко меняющаяся панель информации, а в первых двух — два фреймбуфера для буферизированого сложного рендера. При этом достаточно завести три VDL — в одном в качестве источника сканлайнов указывается первый битмап, во втором — второй и оба из них ссылаются на третий с 40 сканлайнами как на последний VDL в дисплейном списке. В чётных кадрам мы даём видеочипу указатель на первый VDL, а в нечётных — на второй, таким образом последние 40 строк экрана будут заполнены информацией из одного и того же буфера, а первые 200 — из двух разных, с буферизацией.
Cel Engine
Главное что в 3DO есть от «3D» — это конечно же растеризатор, или, как он тут называется — Cel Engine. Почему то фрагменты изображения растеризуемые им называются тут Cel–ами. И что характерно — Cel–ы довольно сильно отклоняются от привычных нам ныне способов рендера и растеризации. Растёт идея Cel Engine как бы из отрисовки обычной 2D–графики — главная его функция заключается в копировании прямоугольного куска изображения из некоего битмапа–источника в некий битмап–приёмник. Возможно они оба должны располагаться в VRAM, но это явно в документации не оговорено. Давайте для начала рассмотрим какие возможности Cel Engine даёт для копирования прямоугольного куска изображения, то есть блиттинга обычного 2D–спрайта, а потом одним приёмом перейдём к 3D. Итак, приёмник изображения должен быть прямолинейным битмапом в 16–битном формате, совпадающим с форматом экранного видеобуфера (хотя он необязательно должен с ним совпадать по адресам). А вот с источником всё намного сложнее. Во первых битмап–источник может быть запакован. Неважен его внутренний формат, запаковать можно что угодно. Паковка осуществляется техникой RLE — повторяющиеся N раз (особо выделены прозрачные) пиксели кодируются двумя байтами, не повторяющиеся — пакуются в полоски по N байт + байт заголовка, где N <= 32. Во вторых — формат пикселей источника может быть довольно разнообразен. Это могут быть пиксели хранящие индексы в таблице 16–битных пикселей (1, 2, 4, 6, 8 и 16 бит) или прямо компоненты 16–битного пикселя (8 и 16 бит). Форматы и того и другого замысловаты — есть возможность включать коэффициенты множителей в информацию о пикселе или так называемый P–бит, о чём ниже. Итак, на этом этапе Cel Engine извлекает из битмапа–источника цвет и превращает его в 16–битный формат пикселя фреймбуфера. А далее возможны варианты. Самый простой — это помещение полученного пикселя в битмап–приёмник. Но данный этап Cel Engine может настраиваться более широко. В максимальном режиме он смешивает два пикселя через заданную формулу — таких формулы может быть задано две, одна из них является текущей, но если в пикселе источника задаётся P–бит, то он на лету может переключить текущий режим. — Источником первого пикселя может быть или битмап–источник или произвольно заданный битмап в памяти, совпадающий по формату с битмапом–приёмником (чаще всего это он и есть). — Источником второго пикселя могут быть те же вещи плюс еще постоянное, заданное значение цвета. — Формула смешивания может умножать и делить RGB–значения в источниках на некоторый набор коэффициентов, далее вычитать их или суммировать между собой и опционально делить на два в конце. Стоит отметить, что Cel не допускает переполнения RGB–компонент. Это всё даёт нам богатый спектр возможностей — от полупрозрачности до затенения. Причём заметьте — можно растеризовать битмап даже не делая его источником пикселей для смешивания. Это интересно ввиду того, что Cel Engine отбрасывает прозрачные пиксели источника еще до фазы пиксельного смешивания, не запуская её. Таким образом можно, например, выставить битмап сложной формы (в силу прозрачных пикселей) Cel–ом, но в процессе смешивания пикселей смешать приёмник с фиксированным цветом, таким образом затенив фрагмент во фреймбуфере. Если тут же нарисовать поверху уже обычным методом этот же Cel с небольшим смещением можно получить как бы картинку с тенью под ней.
А вот теперь начинаем потихоньку переходить собственно к обещанному 3D.
В самом простом режиме блиттинга Cel Engine переносит прямоугольный блок пикселей, но в сложном варианте, с помощью 6 коэффициентов с фиксированной запятой можно настроить произвольные афинно–перспективные трансформации, которые будут применяться к битмапу источника при растеризации. Наглядно это можно себе представить как произвольную возможность задавать вершины четырёхугольника назначения в битмапе–приёмнике. Лучше один раз посмотреть на картинку, чтобы понять:
Вложение
10f4f885c0.gif
В центре изображен «прямоугольный» перенос, самый простой и быстрый, по краям же изображено несколько примеров как можно произвольно «перетаскивать» и «перекручивать» углы уже четырёхугольника в битмапе–приёмнике. Во главе всего по прежнему стоит прямоугольник. При этом важно заметить, что его координаты в источнике могут быть только прямоугольником с выровненными по осям сторонами — здесь нет аналогии с текстурными координатами в привычных ныне методах растеризации полигонов. Вообще сам алгоритм растеризации тут «вырвернут наизнанку». Это можно было заметить уже по тому, что битмап источника может быть запакован. На самом деле что здесь всегда происходит — Cel Engine линейно слева–направо, сверху–вниз обходит по порядку пиксели битмапа–источника и проецирует их в битмап–приёмник. Не наоборот, как делают современные рендеры, которые пляшут от пикселей треугольника спроецированного уже на фрембуфер — выполняя пиксельные шейдеры и текстурные выборки по одному разу для каждого пикселя во фреймбуфере. Cel Engine в 3DO пляшет от пикселей источника и проецирует их один за одним в приёмник — эта процедура выполняется ровно 1 раз для каждого (непрозрачного) пикселя в источнике. Этому есть еще два свидетельства — во первых в FAQ по быстродействию прямо говорится, что уменьшение картинки при растеризации не ускоряет значительно рендер. То есть копирование картинки без изменения размера и копирование картинки с уменьшением размера во фреймбуфере хоть до 1 пикселя занимает почти что одинаковое время! Второй момент касается увеличения картинки при масштабировании — существует флаг «быстрого копирования», который может приемлемо себя повести если картинка сохраняет размеры или уменьшается, но даст пропуски (вплоть до гигантских) между пикселями, если картинка увеличивается. Это может быть использовано даже как спецэффект. На деле документация прямо говорит, что при масштабировании с увеличением Cel Engine тщательно анализирует блоки пикселей в приёмнике которые надо залить одним и тем же пикселем источника и запускает для них двойной цикл этой заливки — это замедляет процедуры и именно это поведение и отключает флаг «быстрого копирования». Еще один момент, связанный с поддержкой 3D есть в том, что консоль понимает порядок отрисовки «по часовой» и «против часовой», может отбрасывать отрисовку того или иного, причём корректно обрабатывая смену направления при самопересечении четырёхугольника. Но больше никакой поддержки 3D в 3DO нет — ни Z–буфера, ни ускорения обработки вершин перед растеризацией, ничего иного больше нет. Всё что аппаратная начинка нам предлагает — это произвольно перекрученные прямоугольники.
Заключение
Вот такой «допотопный» и я бы даже сказал, что неопытный подход к рендеру был у 3DO. Как видно он явно растёт из блиттинга изображений, далее видимо пройдя через блиттинг с масштабированием и вращением эволюционировал в нечто с 3D–потенциалом, но с ограниченными возможностями в плане выбора текстурных координат. Всевозможные «подрагивания» уголков полигонов и подобные пиксельные неаккуратности были здесь частным гостем. Вообще консоль действительно оставляет чёткое послевкусие неопытности: то борьбы с ветряными мельницами, то отсутствия понимания в какую сторону надо было двигать 3D–рендер. Playstation 1 была объективно лучше, современнее и адекватнее потребностям рынка, на что ей хватило год и пары месяцев форы.
Довольно забавная штучка первого поколения 3D и так же как и 3DO базовым элементом сделавшая не треугольник, а четырёхугольник. Терминология тоже в силу молодости индустрии весьма непривычная, так эти четырёхугольники даже с 3Д и освещением по Гуро они продолжают называть спрайтами. Вышла консоль в конце 1994 года то есть за два года до выхода на пользовательский рынок ПК продукции 3Dfx Interactive — графических ускорителей Voodoo, но примерно в то же время когда появилась на свет Sony Playstation.
Нафаршировали систему с каким то даже остервенением. Два 32-битных RISC-процессора Hitachi SH-2 делят общие 1,5 Мб рабочей памяти. Предполагается что второй из них выполняет всякие вспомогательные штуки типа трансформации вершин, но при этом узким местом является доступ к рабочей памяти. Поэтому у процессоров по 4Кб кеша которые во втором переведены в режим 2Кб кеша + 2Кб сверхбыстрой памяти. Но кроме основных процессоров программированию так же поддавался SCU (System Control Unit) — этот модуль разводил данные по шинам системы, содержал DMA-контроллер и DSP гарвардской архитектуры с модулями умножения, в который можно было загружать небольшие программы которые могли опять таки решать задачу умножения на матрицы с одновременной перегонкой данных из рабочей памяти в видеочипы по DMA. Sega в официальном SDK предоставляла несколько полезных микропрограмм для этого модуля. Еще был 4-битный микроконтроллер Hitachi сидящий на таймере, задачах генерации прерываний и опроса данных от периферии (например геймпадов). Он работает всегда и питается от батареи когда системы выключена, видимо через него консоль включается/выключается. Подсистема CD-ROM-а содержит собственный процессор Hitachi SH-1 и 0,5 Мб памяти под буфера ввода. Программировать его нельзя, общение происходит посредством заранее обозначенных команд. Например можно было заставить его закешировать какой либо файл для быстрой подкачки. Звуковая система содержала 32-канальный генератор PCM или FM-звуков, которые подают свой сигнал в особый DSP на 128 инструкций, которые могут делать массу преобразований с этими звуками и в довесок еще работает всё это под управлением опять таки программируемого микроконтроллера 68EC000 (упрощенная версия m68k) который по умолчанию был запрограммирован Sega как midi-секвенсер, но при необходимости его тоже можно было перепрограммировать.
Видеосистема состоит из двух видеочипов — VDP-1 и VDP-2. Каждый имеет выделенные 512Кб VRAM. VDP-1 делит свои пополам на два фреймбуфера по 256Кб. Пока рендерим в один буфер другой отображается на экране. Базовые разрешения — 320x224 и 352x240 пикселей. В них пиксели во фреймбуферах 16-битные. Есть режим повышающий разрешение по горизонтали вдвое, однако при нём отваливается 16-битная цветность и видеорежим становится 8-битным с 256-цветной палитрой. Кроме этого есть режим (interlace) повышающий разрешение по вертикали тоже вдвое, тут уже отваливаются два фреймбуфера и буферизация, так что видимо рисовать надо успевать во время обратного хода луча ЭЛТ, ибо явно написано, что нельзя рендерить во фреймбуфер отображающийся на экране. Скорее всего этот режим пригоден только для вывода статичной графики.
Отрисовка происходит скармливанием видеочипу связного списка команд к отрисовке. Геометрические примитивы называются «parts» и делятся на оттекстуренные (четырёхугольные «спрайты» произвольного искажения и ротации) и неоттекстуренные (одноцветные четырёхугольники или линии). К любым из них может быть применено сглаженное затенение по Гуро, затенение делением компонент RGB на 2 или полупрозрачность арифметическим средним. Как и у 3DO природа отрисовки спрайтов/полигонов позволяет сделать трюк с так называемыми end codes — это специальные значения цветов которые позволяют оптимизировать отрисовку спрайтов с большими регионами прозрачности методом полного пропуска сканлайна при встрече специального значения пикселя означающего end code. Причём т.к. спрайты можно зеркалировать по горизонтали, то пропуск происходит после встречи двух end codes так, чтобы отбрасываться могли ненужные куски в конце растров как при отрисовке справа-налево так и слева-направо. Пиксели 16-битные, но цвета выставляются довольно забавно. RGB-компоненты все по 5 бит и самый старший неиспользуемый бит отведён под признак палитры. Если спрайт пишется во фреймбуфер в RGB-цвете, то в верхнем бите у него выставляется 1 и он уходит потом на телевизор как есть. Но если в верхнем бите содержится 0, то включается режим палетризации — и нижние биты уже означают номер слота в палитре и через этот механизм можно даже управлять порядком отрисовки с VDP-2. Дело в том, что финальное изображение формирует VDP-2 извлекая картинку из фреймбуфера VDP-1 и накладывая на неё до 4 задних фонов и уже итог и выводится на телевизор. Эти задние фоны могут быть битмапами, а могут быть сделаны по полным лекалам 16-битных видеочипов — квадратные сетки замощёных тайлов 8x8 которые можно легко скроллить и даже вращать, причём цвета тайлов могут быть тоже как в RGB-формате так и вхождениями в палитре. Максимальный размер палитры — 2048 вхождений. Так вот — настройками VDP-2 можно управлять порядком наложения слоёв и фреймбуфера вплоть до того, что палетризированные пиксели фреймбуфера будут иметь разный порядок отрисовки, нежели непалетризированные. Таким образом можно генерировать всякие SFX похожие на стенсильный буфер по эффектам. Причём задние фоны могут быть двух типов — обычные и вращаемые. Обычные на самом деле тоже можно вращать, но только по оси Z. А вот вращаемые можно вращать сразу по двух осям, что видимо помогает делать SFX типа уходящих вдаль горизонтов как в Mario Cart на SNES.
Забавна сама архитектура переезда в 3D. Фактически они выделили то что в 16-битных консолях было слоем спрайтов в отдельный фреймбуфер чтобы в него можно было рендерить четырёхгольные спрайты произвольных трансформаций:
Вложение
9934447256.gif
Т.е. как и в 3DO здесь рендер проходил идеологически последовательные шаги по отрисовке обычных спрайтов, потом отзеркаленных спрайтов, потом отмасштабированных, потом просто повёрнутых и уже в конце всего — искаженных любыми способами и даже с интерполяцией затенения по Гуро между четырьмя вершинами. В глубоком отличии от классического (и современного) рендера который идёт по пикселям экрана и делает для них текстурные выборки здесь проход осуществляется по пикселям спрайта с переносом их на экран через трансформации. Поэтому возможен тот же трюк с end codes. Но это приводило так же и к негативным эффектам: так в документации от Sega замечается, что при сильных искажениях спрайта нельзя полагаться на полупрозрачность, потому в один и тот же пиксель экрана могут быть нарисованы несколько пикселей из спрайта, а следовательно они все дадут вклад в затенение итогового изображения. Тем не менее из этого слоя спрайтов можно было формировать по настоящему трёхмерную графику. Стоит так же отметить, что в целях совместимости с «треугольной» графикой уже набравшей обороты система поддерживала вырожденные четырёхугольники с одной общей вершиной. Слои же задних (и передних) фонов остались как были в старых консолях и в принципе могли быть использованы для вывода задних фонов в привычных платформерах, но в полноценном 3D их применение было существенно более ограниченным — панельки с игровой информацией разве что, да пол-потолок в чём нибудь типа Wolf3D (т.е. протяжённая плоскость уходящая в закат)… Так что в итоге подход с четырёхугольными спрайтами потом вымер, т.к. обладал рядом существенных недостатков.
sega saturn, 32 bit, video, 32 бита, architecture, архитектура
avatar aa-dav 17 апреля 2019, 10:00 +18
2 комментария
aa-dav Немного еще посмотрел в то как именно работают палетризированные цвета в Saturn, ибо там сразу было видно, что дела обстоят непростым образом, но за ворохом слов было не очень понятно. Оказалось что и с палитрами там всё очень сложно. Во первых — при рендере текстурированного спрайта в 16-битный фреймбуфер данные о цвете его битмапа могут быть представлены непосредственно как 16-битные значения, а могут быть 4-битными слотами в 16-цветной палитре 16-битных же цветов. Но в любом случае во фреймбуфер попадает 16-битное данное у которого верхний бит контролирует является оно RGB или является цветом в палитре. Так вот когда оно является цветом в палитре существует 8 глобально выставляемых форматов того какие биты в нём отвечают за: а) номер цвета в палитре (до 10 бит) б) порядок отрисовки между задними фонами (до 3-х бит) в) номер расширенного вычисления цвета (до 3-х бит) г) бит «тени» Кроме того для 8-битного режима фрембуфера есть так же 8 форматов как эти же биты, но уже в урезанном количестве распределены по 8-битному данному о цвете в нём. И там такая битовая мешанина из сотен регистров управляющих всякими этими битовыми комбинациями, что как говорится «без поллитры не разберешься». Реально ловлю то же самое ощущение что было в похожем по духу эпохи 3DO — вся эта битово-палитрово-слоевая мехника переусложнена до жути. Мегадрайв от той же фирмы был просто гимном лаконичности и простоты своей графической начинки — одна палитра, один палитровый режим и для спрайтов и для тайлов, но пасаран. Тут же прям им крышу сорвало на то как впихать в биты как можно большее число всяких палитр, режимов и цветов. Сомневаюсь что даже половина этих всех вещей была в реальности востребована.
А вот дальше еще на другом форуме подсказали, что была такая весьма забавная видеокарта как Diamond Edge 3D — согласно википедии первая видеокарта на пользовательском рынке ПК с аппаратным ускорением (95-ый год). Так вот это был некий синтез видео- и звуковых чипов из Sega Saturn в виде платы для IBM PC. И вот тут всё стало совсем интересно, ведь Diamond Edge 3D в сердце своём содержит чип NV1 который разработала, да, nVidia. Похоже, что это был одна из первых попыток этой фирмы продвигать 3Д в массы. В статье про Sega Saturn этому посвящена всего одна строчка (мой перевод):
Шеффилд сказал, что использование Сатурном четырёхугольников подорвало поддержку системы третьими сторонами, но поскольку «nVidia вложилась в четырёхугольники» в то же время есть «отдалённая возможность», что они смогут «стать стандартом вместо треугольников», если каким то образом, магически, Сатурн стал бы самой популярной консолью той эпохи".
И удивительно, но в русском википедии есть гораздо больше интересной информации, чем в английской:NV1
Использование квадратичных поверхностей было элегантным и абсолютно новым решением в 3D-мире. Хотя теория была придумана давно, в железе такого до этого никто не делал. Главная идея заключалась в том, что в 1995 году реализовать операцию деления 1/z в железе была невероятно сложно и дорого, и в результате этого имплементировать перспективную проекцию было очень трудно. Классический подход, заключавшийся в линейной аппроксимации гиперболической функции, имел свою проблему аппроксимации в окрестности нуля и требовал сложного программного обеспечения. Квадратичная теория, использованная в NV1, аппроксимировала функцию 1/z параболической интерполяцией и такая интерполяция по качеству превосходила кусочно-линейную, которая была использована в решениях конкурентов. … Попытка исследовательской группы NVIDIA портировать квадратичную технологию на API Microsoft провалилась. Попытка выполнить наложения текстуры и операцию clipping приводило к уравнениям 5 степени невычислимыми в радикалах. Хотя демонстрационные примеры с квадратичными поверхностями выглядели довольно неплохо, работа с ними оказалась чрезвычайно трудной. … Дальнейшая разработка NV1 под новым названием — NV2 была остановлена, NV1 производство было свернуто. В 1996 году Nvidia начала разработку классического акселератора.
Хех, оказывается за этими квадратностями стояла никто иная, как сама nVidia и это был её первый блин комом.
Восьмибитная портативная консоль от Nintendo — Game Boy вышла в 1989 году — через 6 лет после выхода домашней стационарной Famicom/NES (известной у нас под брендом Денди) и очень сильно опередила всех своих конкурентов. Фактор портативности довольно сильно урезал возможности аппарата и чёрно–белые игры на нём выглядели бледными копиями аналогов на старшем брате, но популярности это нисколько не помешало. А в 1998 году вышла обновлённая версия консоли — Game Boy Color, которая сильно раздвинула и цветовые и другие возможности при этом сохранив обратную совместимость. Сегодня мы обзорно рассмотрим эти две консоли изнутри с точки зрения программиста.
Центральный Процессор и память
Центральный процессор Game Boy (GB) и Game Boy Color (GBC) — это Sharp LR35902, который я описывал в отдельной статье. Если вкратце, то это очень сильно урезанный 8-битный процессор Zilog Z80 который в свою очередь — сильно улучшенный Intel 8080. В процессе урезания (видимо для экономия энергии для формата портативки) Sharp LR35902 потерял почти все нововведения и усовершенствования от Z80 и даже некоторый функционал i8080, поэтому стал несовместим ни с тем ни с другим, хотя большая часть базовых инструкций имеет тот же двоичный формат. Помимо этого были так же добавлены новые инструкции, например, позволяющие быстро работать с последними 256 байтами оперативной памяти (нечто похоже на zero-page в MOS 6502 в Famicom/NES/Денди, но в реалиях архитектуры i8080). В GB процессор работает на частоте 4.2Мгц, а в GBC может быть переведён в ускоренный режим с 8.4МГц, хотя даже в GBC рекомендовалось работать на пониженной частоте при возможности, чтобы экономить батарею. Однако, несмотря на то, что переключение между частотами совершалось программно, но делалось это не мгновенно, а только в определенный момент VBlank и экран при этом явственно моргал, так что невозможно было переключаться несколько раз за кадр и даже просто каждый кадр во время игрового процесса — так что рекомендацию работать на пониженной частоте игры часто не могли выполнять даже частично.
В типичном для 8-биток адресном пространстве в 64 Кб на первые 32 Кб памяти консоли маппится ROM картриджа (возможно с переключением банков ROM через Memory Bank Controller (MBC) — контроллер банков памяти), а в последних 32 Кб памяти находятся 8 (GB) или 16 (GBC) Кб видеопамяти, 8 (GB) или 32 (GBC) Кб оперативной памяти, порты ввода-вывода, таблица спрайтов и 127 байт ячеек быстрой «верхней» памяти. При этом в GBC доступ к дополнительным RAM видео- и рабочей памяти производится тоже маппингом страниц, так что раскладка памяти выглядит следующим образом:
0000-3FFF (первые 16Кб) - банк 00 ROM картриджа (неизменяемый) 4000-7FFF (вторые 16КБ) - переключаемый банк ROM картриджа (от 01 до NN в зависимости от ёмкости картриджа) 8000-9FFF (8Кб) - VRAM видеочипа (в GBC переключается между двумя банками по 8Кб) A000-BFFF (8Кб) - дополнительное ОЗУ на картридже, если есть (возможно с переключениями банков) C000-CFFF (4Кб) - банк 00 RAM консоли D000-DFFF (4Кб) - банк 01 RAM консоли (в GBC можно переключать на банки 01-07) (т.е. в GB - 8Кб внутренней RAM, а в GBC - 32Кб, но со страничным доступом) E000-FDFF (7680 байт) - "зеркало" C000-DDFF, обычно никак не используемое FE00-FE9F (160 байт) - таблица атрибутов спрайтов - Sprite Attribute Table (OAM) FEA0-FEFF (96 байт) - не используется FF00-FF7F (128 байт) - порты ввода-вывода FF80-FFFE (127 байт) - быстрая "верхняя" память (High RAM - HRAM) FFFF-FFFF (1 байт) - регистр управления прерываниями
Здесь можно отметить, что Nintendo видимо по привычке замапило порты ввода-вывода в адресное пространство ЦП и поэтому специализированные команды ввода-вывода в нём от Z80 и i8080 тоже пошли под нож. Зато сами порты ввода-вывода были размещены в последних 256 байтах RAM из-за чего к ним стало возможным обращаться новыми быстрыми командами.
Видеочип
Как и принято в таких консолях — единицей изображения является квадратный тайл 8x8 пикселей. Разрешение LCD экрана — 160x144 пикселя, что вмещает ровно 20x18 тайлов. Изображение на экране компонуется из трёх составляющих: — задний фон (background) — квадратно-гнездовая сетка из тайлов с аппаратным скроллингом во всех направлениях. — окно (window) — квадратно-гнездовая сетка из тайлов которую можно «приклеить» верхним-левым углом к любой координате экрана и она будет выводится в пикселях ниже и правее над задним фоном. не скроллится, а в остальном устроена как задний фон. применяется для панелей с игровой статистикой. — спрайты — до 40 спрайтов размером 8x8 или 8x16 (размер выбирается для всех сразу) до 10 спрайтов в одной строке сканлайна (большее количество спрайтов в строке просто не рисуется) Любую из составляющих можно включить или отключить, как и весь LCD-экран целиком. Напрашивается сравнение с Famicom/NES/Денди, где было 64 аппаратных спрайта с 8 спрайтами в строке.
У классического Game Boy (GB) монохромная цветность с четырьмя градациями черного/белого, поэтому на 1 пиксель тайла требуется 2 бита информации. Следовательно целиком описать изображение одного тайла можно 16 байтами. 8 строк хранятся последовательно по 2 байта на строку при этом первый байт в строке хранит в каждом бите нижний бит номера цвета в соответствующем пикселе, а второй — верхний. Первые 6144 байт видеопамяти у GB отведены под последовательный массив таких изображений — 384 тайлов — тайловые данные (Tile Map Data) или, как сейчас выражаются — тайлсет. Технически эта зона как бы поделена на две пересекающихся области по 256 тайлов — с адресов от $8000 до $8FFF и от $8800 до $97FF. При этом 128 изображений тайлов в центральной трети этих 6 Кб у них получаются общими. Тайлы первой области жёстко привязаны к спрайтам, т.е. спрайты могут брать изображения для себя только из первых 256 тайловых данных — как тайлов с номерами от 0 до 255. Это относится и к заднему фону и окну, но их еще можно (но только одновременно) переключить на вывод тайлов из второй области. Тут правда происходит одно усложение тайлы с номерами 0..127 лежат в её второй половине (начиная с адреса $9000), а тайлы с номерами 128...255 — в первой, той самой которая пересекается с первой областью. Так сделано чтобы общие тайлы в обеих областях имели одинаковые номера-индексы. Здесь опять можно сравнить с Famicom/NES/Денди — там было два полностью независимых банка для фона и спрайтов по 256 тайла в каждом, т.е. 512 уникальных тайла против 384 в GB.
Задний фон
Задний фон и окно в GB выводят квадратно-гнездовую сетку тайлов из так называемой карты тайлов — это квадратный массив 32x32 байт каждый элемент которого означает номер тайла который надо вывести в фоне или окне в данном месте. Т.к. размеры экрана у GB(C) скромные, то в отличие от Famicon/NES/Денди тайловой карты 32x32 достаточно для полноценной прокрутки заднего фона по всем направлениям. Карта тайлов (точнее даже их индексов) 32x32 занимает 1024 байта и формирует виртуальную сетку в 256x256 пикселей, часть из которых видна в заднем фоне или окне. Последние 2048 байт видеопамяти отведены под две таких карты (адреса 9800-9BFF и 9C00-9FFF) и любую из них можно выбрать в качестве источника изображения как для заднего фона так и для окна (тут уже независимо друг от друга). При этом для заднего фона в двух портах ввода-вывода мы задаём какой пиксель этой виртуальной пиксельной карты будет изображаться в левом-верхнем углу экрана, а остальное изображение замостит экран плиткой тайлов и если потребуется «провернётся» по краям экрана, чтобы стал возможен произвольный скроллинг (см. статью про Famicom/NES/Денди для подробностей). А для окна аналогичные два порта ввода-вывода указывают уже координату на экране где начнётся вывод его содержимого — при этом никаких проворачиваний совершаться не будет.
Таким образом видеопамять GB (и первую страницу видеопамяти GBC) можно описать так:
8000-87FF (2 Кб) - тайлы 0..127 первого тайлсета 8800-8FFF (2 Кб) - тайлы 128..255 первого и второго тайлсетов 9000-97FF (2 Кб) - тайлы 0..127 второго тайлсета 9800-9BFF (1 Кб) - тайловая карта 0 9C00-9FFF (1 Кб) - тайловая карта 1
Интересно, что несмотря на монохромность GB в тайловых данных хранятся не непосредственные значения цвета на экране, но индексы в одной из трёх палитр, при этом каждая из палитр это всего лишь один 8-битный порт ввода-вывода, т.к. четыре группы по два бита полностью описывают одну палитру — какое из четырёх значений пикселя в тайловых данных к какой из четырёх возможных интенсивностей света приведут. Одна палитра используется для фона и окна, а две других — для спрайтов (в каждом спрайте хранится в одном бите какую из двух он использует), но нулевой цвет в спрайтах всегда означает прозрачность, поэтому оборудованием игнорируется. Именно из-за этого наличия казалось бы не очень нужных примитивных палитр в GBC удалось несложным образом раскрасить многие из уже существующих игр для GB.
В Game Boy Color (GBC) вещи становятся сложнее — в режиме GBC он обзаводится второй страницей видеопамяти (по тем же адресам — между ней и обычной страницей надо переключаться записью в порты ввода-вывода) и полноценными палитрами с цветностью. Существуют две палитры — для заднего фона/окна и отдельно для спрайтов. В каждой палитре 32 ячейки 16-битных цветов при этом они считаются разбитыми на 8 субпалитр по 4 цвета в каждой. Обновление цветов в палитрах осуществляется через порты ввода-вывода.
Вторая страница видеопамяти в GBC сделана довольно просто — в первых 6 Кб её в точно таком же формате как и в первой хранится еще один такой же по объёму тайлсет в 384 тайла — таким образом в GBC количество тайлов расширено до 768 штук. А в последних 2 Кб второй страницы видеопамяти ровно «напротив» каждого байта/номера тайла в первой странице (по тому же адресу после перемаппинга) хранится байт дополнительных атрибутов, где задаются: — номер страницы в которой изображение тайла находится (0..1) — номер палитры для тайла (0..7) — вертикальное и/или горизонтальное зеркалирование тайла в клетке — подавление приоритета спрайтов (безусловный вывод тайла поверх спрайтов) Как видно графические возможности заднего фона и окна в GBC были значительно улучшены по сравнению с GB (и даже Famicom/NES/Денди, где даже и окна не было и всяческие статус-бары надо было делать техникой HBlank-отсечения).
Спрайты
Таблица спрайтов хранится в портах ввода-вывода в 160 байтах начиная с адреса $FE00. Каждый из 40 возможных спрайтов описывается четырьмя подряд идущими байтами: 1) координата Y увеличенная на 16. правильный способ скрыть спрайт — вывести его за экран по координате Y. 2) координата X увеличенная на 8. даже если спрайт выведен за экран по координате X он влияет на максимальное число спрайтов в строке, поэтому см. пункт выше. 3) номер тайла для отображения (0..255) 4) набор флагов: — приоритет — находится спрайт под или над задним фоном (может подавляться в GBC) — вертикальное и/или горизонтальное зеркалирование — для режима GB бит выбора первой или второй палитры — для режима GBC номер палитры (0..7) — для режима GBC выбор страницы памяти где находится тайл (0..1) Есть глобальная настройка — отображается каждый спрайт одним тайлом (8x8) или двумя тайлами один друг под другом (8x16) — в последнем случае номер тайла должен быть чётным числом (в железе нижний бит номера просто игнорируется) — под этим номером выводится верхний тайл, а нижний берется со следующим (нечётным) номером. Здесь можно понять почему максимальное количество разных цветов которое (без трюков) консоль может отобразить на экране — это 56. В разных плитках фона можно задать по 4 цвета в 8 разных субпалитрах, что даст нам первые 32 цвета. И почти то же самое происходит с восемью субпалитрами спрайтов, но т.к. в спрайтах нулевой цвет всегда прозрачен, то они могут дать нам только 3*8=24 цвета. Поэтому в сумме имеем 56 возможных цветов в одном кадре.
Прочее
Чтение и запись в видеопамять, палитру и таблицу спрайтов можно осуществлять только в моменты когда видеочип с ней не работает — поэтому есть порты ввода по которым можно понять наступил ли подходящий момент и развитая система генерации прерываний. Видеочип может генерировать прерывания по VBlank, HBlank и по достижению номера текущего рисуемого сканлайна заданного в порте ввода-вывода значения (может использоваться для реализации сложных HBlank-отсечений). Существует DMA-канал которым можно инициировать быструю передачу 160 байт из памяти в таблицу спрайтов, её полезно запускать во время VBlank заранее подготовив таблицу памяти в рабочей памяти. В GBC так же существует дополнительный DMA-канал которым можно организовывать передачу из почти любого места в RAM или ROM в почти любое место в VRAM. При этом программа либо должна обеспечить запуск DMA-передачи в момент когда видеочип не читает видеопамять, либо задать такой режим, когда DMA-контроллер проводит передачу порциями по 16 байт в момент наступления прерываний HBlank.
За звук в GB отвечает типичный для 8-битного поколения набор генераторов звука, на котором я не буду подробно останавливаться, опишу только общие возможности: — один генератор прямоугольного сигнала с огибающей и автоматическим изменением тона — один генератор прямоугольного сигнала с огибающей — 4-битный PCM-канал небольшого банка памяти — генератор белого шума Имелся так же звуковой вход от картриджа, видимо для потенциального расширения звуковых возможностей.
Оставшиеся порты ввода-вывода обеспечивали взаимодействие с кнопками, серийным портом для связи с другими устройствами, таймером — от всех них, кстати, могли приходить еще прерывания. В GBC так же еще был инфракрасный порт.
Как и в Famicom/NES/денди контроллеры банков памяти не встраивались в саму консоль, а всегда, по необходимости, находились на картридже. Но их число судя по всему не превышает десятка штук в отличие от того зоопарка что был на Famicom. Типовые MBC позволяли увеличить суммарный ROM картриджа до 2 Мб и встроить в картридж энергозависимую SRAM на батарейке для сохранений игр. Таковыми были мапперы MBC1 и MBC2. MBC3 кроме этого содержал еще часы реального времени в формате день: час: мин: сек, где день мог меняться в интервале от 1 до 512, что позволяло сохраняя текущий год в память сохранений автоматически поддерживать правильность даты при условии что игра на картридже включается не реже чем раз в 512 дней. Забавно, что Nintendo не выпустило маппера с маркировкой MBC4 — скорее всего из-за негативного отношения к «плохой» цифре 4 в японской культуре, а сразу перешло к MBC5. MBC5 был первым маппером умеющим работать на удвоенной частоте GBC и поддерживал до 8 Мб ROM картриджа. А вот MBC7 кроме всего прочего имел в своём составе двухосевой акселерометр ADXL202E и 256 байт энергонезависимой памяти (EEPROM)
Таким образом по моим ощущениям Game Boy заметно отставал от Famicom/NES/Денди по сумме своей технической начинки, а вот Game Boy Color при таком же отставании по некоторым статьям по другим даже заметно превосходил.
gb, gbc, game boy, game boy color, 8bit, LR35902, консоль, видеочип
Atari Jaguar — консоль пятого поколения, вышла в 1993 году почти одновременно с 3DO Interactive Multiplayer, но как и последняя проиграла гонку вооружений Playstation 1, которая появится годом позже.
Конструктивно можно выделить в консоли 3 главных чипа:
центральный процессор Motorola 68000 первых поколений, т.е. несмотря на 32-битную архитектуру памяти и регистров шина данных и ALU этого процессора 16-битные, отчего по строгости классификации его причисляют к 16-битным процессорам (как в Sega Mega Drive) чип «Том» занимающийся графикой чип «Джерри» занимающийся звуком
Консоль имеет 16-мегабайтное адресное пространство куда замаплены 2 Мб основной памяти, 6 Мб ROM картриджа и многочисленные порты ввода-вывода. 2 Мб основной памяти (RAM) имеет довольно сложное внутренее устройство и разводку по шинам. К ней могут с разной степенью свободы обращаться почти все компоненты системы, поэтому там создана довольно сложная система правил взаимных блокировок и распределения по разрядностям и шинам. Так, например, ЦП m68k может обращаться к памяти только 16-битными считываниями/записями за раз как максимум. Но тот же чип «Том» может обращаться к большей части памяти как к 64-битным значениям (с другой стороны к некоторым, выделенным кускам — только как к 32-битным). С одной стороны возможность адресовать память чипом «Том» 64-битными значениями подкрепляет позиционирование консоли как 64-битной системы, но с другой стороны ЦП может с ней обращаться только как 16-битный процессор. Тут еще имеет место быть одна забавность — в основе своей документация использует классическую терминологию в отношении битности ячеек памяти:
8-битные значения называются байтами 16-битные — словами (words) 32-битные — длинными словами (long words) а вот 64-битные значения документация называет «фразами (phrases)», что я встречаю впервые, видимо на заре 64-битности еще толком не договорились о терминологии. сейчас такое привычно называть «четверными словами (quad words)»
Чип «Том» — графика
Графический чип «Том» сам по себе является многокомпонентной системой. Он состоит из:
Процессора объектов (object processor) — это единственное в системе 64-битное вычислительное ядро, но… его нельзя программировать. Графического процессора (graphics processor) — программируемый 32-битный RISC-процессор — в документации он нередко называется GPU, но в современных реалиях это выглядит немного неправильно, GPU это скорее весь чип «Том» целиком. Блиттера (blitter) — ядра, умеющего быстро перекидывать куски изображения в памяти с аппаратной поддержкой Z-буфера и затенения
Процессор объектов (object processor)
Именно он формирует изображение на экране. И делает это он довольно любопытным способом. Цветность может быть 16-битной (RGB или CMY(k)) или 24-битной (True Color). В отличие от типичных ПК процессор объектов не поддерживает некоего выделенного экранного буфера который построчно выводится на экран. Непосредственно выводится на экран только один из двух так называемых «буферов строк». Это два региона памяти в портах ввода-вывода процессора объектов размером 360 32-битных ячеек. Если цветность видео выставлена в 24 бита, то 32-битные ячейки буферов строк отводятся под каждый пиксель выводимого изображения (8 бит не используется) и таким образом предельное разрешение по горизонтали составляет эти самые 360 пикселя. Если же цветность выставлена в 16 бит, то каждая 32-битная ячейка буфера строки хранит по два соседних пикселя и максимальное разрешение по горизонтали становится 720 пикселей. В каждом сканлайне процессор объектов выводит один буфер строки на экран и в это же самое время перерисовывает второй в фоне, так что на следующей строке буфера поменяются местами и выводится будет второй, а строится первый. Построение теневого буфера строки происходит во время прохода по так называемому «списку объектов» — именно поэтому процессор объектов называется как называется. В начале кадра в определенный порт ввода процессора объектов надо записать адрес текущего объекта в основной памяти консоли. Далее процессор объектов в каждом сканлайне делает проход по нему конструируя теневой буфер строки. Размеры объектов всегда кратны 8 байтам (64 битам или «фразам») и они занимают от 1 до 3 фраз. Всего возможно 5 типов объектов:
1. битмап/картинка (занимает 2 фразы) — в этом объекте хранятся описание некоего битмапа в основной памяти, часть которого надо вывести на экране, а так же указатель на следующий объект в цепочке команд. Тут используется вот какой подход — в описании объекта указано:
с какой позиции Y на экране он начинается по вертикали (ypos) какую высоту он имеет (height) в каком месте основной памяти его пиксели располагаются (data) какую битность они имеют (depth) (поддерживаются 1/2/4/8 бита на пиксель через глобальную 256-цветную палитру и 16 или 32 бита на пиксель direct mode) для палетризированных режимов менее 8 бит на пиксель указывается номер субпалитры внутри глобальной с какой координаты по горизонтали и сколько пикселей в строке надо вывести (xpos и iwidth) насколько надо увеличить указатель data (dwidth) чтобы перейти в следующей строке к следующей порции изображения указатель на следующий объект в списке (link)
Так же можно отразить битмап по горизонтали. И вот как происходит обработка таких объектов процессором объектов: пока рисуемые сканлайны еще не достигли верхнего края объекта (они меньше YPOS), то он просто пропускается пока YPOS не сравняется с номером текущего сканлайна — тогда он считается активным. Текущая строчка (по адресу data) пикселей активного объекта рисуется в буфер строки и у объекта height уменьшается на 1 и data увеличивается на dwidth. Когда при отрисовке следующих сканлайнов обнаружится, что height стал равен 0, то объект перестаёт считаться активным и перестаёт рисоваться — он просто пропускается. В любом случае далее происходит переход к следующему объекту по адресу link. Тут важно заметить, что объекты сами по себе являясь описаниями реальных картинок в памяти во первых могут ссылаться на одни и те же физические картинки, во вторых — после построения кадра им надо восстанавливать описания: уменьшенные до нуля height и инкрементированные data. Таким образом видеочип Atari Jaguar реализует построчную отрисовку в стиле 8/16-битных консолей, но в то же время рисует он в строку сканлайна произвольные битмапы, как более мощные системы. Выделенного буфера кадра нет, потому что таким буфером кадра без ограничений может быть произвольный регион памяти. При этом с помощью прозрачности и порядка отрисовки можно накидывать их поверх друг на друга до тех пор пока по таймингам проход по списку объектов будет влазить в отрисовку сканлайна — таким образом легко реализуются произвольные спрайты в т.ч. хранящиеся в больших атласных ресурсах.
2. масштабированный битмап/картинка (занимает 3 фразы) Всё то же самое, что и (1), но с добавкой 1 фразы где описаны коэффициенты масштабирования
3. вызов GPU (1 фраза) — процессор объектов останавливается вызывав прерывание графическому процессору. и он возобновит работу когда графический процессор даст обратный сигнал. Эта команда позволяет процессору объектов вызвать графический процессор и подождать пока тот где-нибудь что-нибудь нарисует. что-то, что потом будет участвовать как данные в следующих командах в списке. Важно, что графическому процессору при этом отдаётся остаток фразы самой этой команды, где можно раположить какую то полезную нагрузку-параметры.
4. переход (1 фраза) Эта команда позволяет перенаправить обработку списка команд на какой то другой адрес в памяти — как безусловно так и по ряду условий. В числе условий можно использовать сравнения номера текущего рисуемого сканлайна с константой или состояние программируемого бита в портах ввода-вывода процессора объектов.
5. конец (1 фраза) — на этой команде процессор объектов останавливает построение теневого буфера строки и ждёт следующего сканлайна для продолжения.
Таким образом процессор объектов являясь одновременно генератором видеосигнала так же способен выполнять задачи растрового совмещения разных изображений (как в 16-битных консолях без фактического блиттинга!) с разбиением областей экрана на разные прямоугольные области с разными данными или спрайтами. Но если мы хотим рисовать трёхмерную графику, то этого нам недостаточно. Тут вступают в роль следующие компоненты чипа «Том».
Графический процессор (GPU)
Графический процессор несмотря на своё название на самом деле является ничем иным как 32-битным RISC-процессором с выделенными 4Кб памяти (доступными однако остальным компонентам системы, но если они к ним не обращаются, то достигается высокая степень параллельности). Похоже что это какая то кастомная разработка, определенные корни не просматриваются, но в целом он очень типичен для философии RISC. Как можно более простое ядро (без микрокода, например) заточенное, однако на скорость работы. Большое количество регистров — 32 для обычной работы и 32 теневых для обработки прерываний. Простой формат инструкций и высокая степень конвееризации за счёт простого цикла обработки инструкций, арифметико-логических команд вовлекающих только регистры и работа с памятью только через инструкции load/store с простыми режимами адресации. Присутствуют команды умножения (16-битные) и деления (32-битные), а так же быстрая битовая прокрутка (т.е. barrel shifter). И вот тут вылезают некоторые «неаккуратности». Основная цель поставленная перед этим ядром была — скорость. Всё ради скорости и в то же время внутренней простоты. Во первых этот процессор использовал принцип «delay slot» — это когда инструкции пытались исполнятся как можно быстрее следом друг за другом и пока одна еще только исполнялась вторая уже помещалась во внутренний буфер команд. Это приводило к тому, что даже встретив инструкцию перехода jmp процессор уже совершив даже переход всё равно обязательно следом исполнял следующую инструкцию по старому адресу, что иногда требовало размещать после инструкций холостые nop-ы:
jmp addr nop ; эта инструкция обязательно исполнится даже после совершения перехода
Но для эффективности и плотности кода лучше было размещать там инструкции так, чтобы они всё-таки приводили к полезным вычислениям. В силу максимальной простоты внутреннего устройства это приводило к такой проблеме, что в инструкциях следующих сразу за переходами нельзя было использовать инструкции полагающиеся на содержимое счётчика инструкций (например другие переходы), т.к. параллелизм приводил к путанице между новыми и старыми значениями до и после переходов. Но «delay slot» был только началом — кроме этого этот процессор использовал конвееризацию — одновременное исполнение сразу нескольких инструкций потока команд в разных фазах. Например пока одна инструкция уже производит сложение своих аргументов следующая за ней уже могла загружать свои аргументы на вход в арифметико-логическое устройство, а предыдущая уже могла сохранять какое то значение в память. Поэтому нередко производительность могла достигать 1 такта на инструкцию, хотя на самом деле это достигалось тем, что 4 инструкции выполняющиеся в разных своих фазах по 4 такта выполнялись одновременно не мешая друг-другу. Всё это в общем то классика процессоростроения и здесь любой знакомый с предметом вспомнит, что иногда такие инструкции мешали друг другу зависимостью своих входных аргументов от выходных — иногда чтобы вычислить одну инструкцию надо было сперва дождаться пока предыдущая сохранит свой результат. Так было и здесь. И механизм такого «разруливания» конфликтов назывался «score-boarding». Но то ли из-за спешки при разработке, то ли из-за желания максимально упростить внутреннее устройство процессора score-boarding… не всегда работал правильно. Поэтому в официальной документации по разработке на Atari Jaguar есть раздел «Hardware Bugs & Warnings», т.е. «Аппаратные Ошибки и Предупреждения». И там ничуть не смущаясь написано, что score-boarding в GPU получился… с багами. Например он вообще не работал с операциями сохранения (store) с индексацией. Это значило, что инструкции:
из-за того, что div выполняется очень долго (и с особой степенью параллелизма), то store успевает по стадиям проскочить вперёд и из-за того, что используется индексация (+6), то глючный score-boarding этот момент обязательно прошляпит и получится ерунда. поэтому создатели просто сказали — вставляйте фиктивную инструкцию or r3, r3:
с ней score-boarding уже притормозит пока результат от div не будет готов и store уже проскочит как надо. И это далеко не единственный такой «баг» (или «фича»?). Еще нельзя было размещать инструкции деления (div) сразу друг за другом — вторая просто успевала вклиниваться своим началом в работу первой. Заглючить могли даже простые move-ы, если выпадет неприятная последовательность инструкций когда score-boarding еще мог «отказать». И многое другое. Видимо для пущего упрощения схем. Лучше всего графический процессор работает в рамках своих «родных» 4Кб памяти. При этом он даже способен исполнять код находящийся в основной памяти, но тогда во первых просаживается скорость всей системы и опять таки начинаются какие то внутренние проблемы и «отваливаются» некоторые варианты инструкций переходов. Поэтому правильным использованием графического процессора является загрузка в него программ и данных (причём лучше всего через блиттер, т.к. в механизме DMA оказался опять (!) какой то баг из-за которого воспользоваться им для этих целей нельзя) в его родные 4Кб и чтобы он переваривал их там. Заодно отмечу, что на этом месте ознакомления с документацией у меня возникло стойкое ощущение, что систему сделали впопыхах и выпустили на рынок в массовом порядке не успев толком отладить и протестировать.
Блиттер (blitter)
Блиттер — это вспомогательный блок для графического процессора способный быстро переносить блоки пикселей из одного места памяти в другое с некоторой их обработкой. Предполагается, что графический процессор должен заниматься вычислением вершин и характеристик графических примитивов, а блиттер — рисовать их пиксели. Блиттер способен:
* просто копировать куски памяти * копировать и заливать прямоугольники * рисовать линии * вращать и масштабировать изображения * рисовать горизонтальные линии пикселей затенённых по Гуро полигонов с Z-буфером
Таким образом чтобы рисовать те же полигоны в 3D — GPU должен вычислить из каких горизонтальных линий они состоят, какие у них параметры освещения и 3D в концах отрезков и дать команды по их отрисовке блиттеру. Активация блиттера производится записью в его многочисленные регистры параметров с последним из них — регистром Control, что активирует выбранную функцию. Весьма похоже на программирование DMA-контроллеров в других описанных мной консолях.
Чип «Джерри»
Чип «Джерри» тоже является многокомпонентной величиной с таймерами, DMA-контроллерами, звуковыми каналами, серийными интерфейсами, портами ввода от джойстиков, но главной его компонентой является почти такой же RISC-процессор как GPU, только больше заточенный под обработку звука и называемый DSP.
Звуковой процессор (DSP)
Это почти такой же процессор как GPU, но больше заточенный под обработку звука. Изменения включают в себя: — увеличенный до 8Кб объём внутренней памяти — 2Кб ROM-таблиц для синтеза звука (синусоиды, треугольные формы и т.п.) — увеличенная точность аппаратного умножения — несколько дополнительных инструкций для упрощения типовых задач работы со звуком
В целом консоль «изнутри» на меня произвела впечатление больше аккуратности чем тот же 3DO, но меньшей простоты для разработчика (т.к. самому надо писать программы для рисования трёхмерной графики на GPU), чем Playstation 1.
aa-dav 17 мая 2019, 09:01 В качестве бонуса еще приведу свой пост с gamedev.ru по поводу сабжа:
Те кто читал внимательно предыдущую статью про архитектуру Atari Jaguar могли заметить, что описывая блиттер консоли были упомянуты и затенение по Гуро и Z-буфер, но ничего не было сказано про текстурирование. И это действительно так — блиттер не умел текстурирование вообще. А ведь даже современник — 3DO знал текстурирование (хотя наоборот не знал Z-буфер), но там другая история и весьма иной аппаратный ускоритель. Действительно, если посмотреть на игру идущую в комплекте с консолью на её старте, то можно воочию увидеть, что всё 3D состояло из освещённых, но нетекстурированных треугольников:
видео
Тем не менее игры с текстурированием были, но как можно понять по недолгому размышлению в этом случае игра уже не использовала аппаратный блиттер, а целиком возлагала процесс рисования треугольников на программируемое RISC-ядро чипа Том (а может даже припрягала в помощь к нему подобное ядро из чипа Джерри).
В связи с этим было интересно натолкнуться на интервью зарубежного компьютерного журнала о видеоиграх Edge с Джоном Кармаком после того как был анонсирован выход игры Doom на Atari Jaguar, но процесс разработки был еще в середине процесса. Приведу лишь ссылки на скрины (т.к. они сами довольно большие по размеру):
сканы
Если вкратце, то Кармак весьма нахваливал консоль и даже выразился о ней как о лучшей игровой платформе на тот момент времени. По его словам у него заняло две недели от начала портирования Doom на Atari Jaguar прежде чем хоть какая то картинка на телевизоре появилась, но с ужасным фреймрейтом. Он подтверждает, что основной процессор m68k слишком медленный, но дополнительные RISC-ядра — это вестчь! Но ему требуется время чтобы переписать код так, чтобы он помещался стадиями в маленькие кусочки памяти RISC-ядер (см. описание Atari Jaguar выше если еще не). Причём сперва он любопытства ради начал портировать движок Wolf 3D со SNES на Atari Jaguar и когда «пятнадцатью сидиромов позднее» у него получилась картинка — он послал результат в Atari и они дали добро на порт Doom. Но до этого Джон потратил три недели чтобы сделать лучший порт Вольфеншейна среди всех прочих — он работает на 30 фпс с вчетверо большей деталистичностью чем на ПК и даже звук звучит на 22 кГц, что в трое больше чем на ПК. В общем этим портом он остался доволен. Но Doom на момент написания статьи всё еще представлялся тёмной лошадкой — Кармак говорит, что текстурирование будет выполнятся не совсем так же как на ПК, но по схожему принципу. Консоль весьма хвалит называя лучшим игровым железом на тот момент на рынке. Положительно отзывается о процессоре объектов, т.к. тот и картинку позволяет легко компоновать из разных сюрфейсов так и спрайты поверх выводить в совершенно свободном виде. Так же он хвалит модель цвета CRY (нечто вроде CMY(k), как я писал в статье) и вообще называет её лучшей в мире моделью цвета для видеоигр ибо затенение (освещение) становится тривиальной штукой (просто канал яркости это отдельный канал яркости). Ну а 16-битный цвет сам по себе должен был позволить выйти за рамки ограничений ПК-шной 256-цветной палитры намного и всерьёз. Однако уже здесь Кармак признавал, что Jaguar не удастся добиться плавности в 30 фпс какую Doom имел на процессоре класса Pentium — тут он на тот момент разводил руками: «посмотрим как получится». Здесь же он упоминает, что несмотря на то, что он сперва был недоволен тем, что Atari пытаются разработать собственные RISC-процессоры, но в итоге он нашёл их довольно быстрыми и приятными в разработке — единственный минус — малый объём локальной памяти. Ну и то, что в них есть баги (лол!). Так что единственная аппаратная ошибка которую, по его мнению, совершила Atari — это то, что в качестве ЦП в консоли стоит m68k. RISC-ядра по его мнению в 20 раз быстрее.
Далее разговор немного отходит от консоли, но просто ради фана упомяну интересные моменты. В этот момент Кармак говорит, что в разработке находятся три игры на движке Doom: Doom II, некая Druid от Raven Software («фентезийная версия Doom») и Strife от Sygnus Studio. И что уже неиллюзорно пахнет Quake-ом. Просто факты о том о сём: разработка графического ядра Wolf 3D заняла месяц, разработка графического ядра Doom заняла уже 3 месяца, но потом пришлось потратить 2 месяца на полное переписывание его под новый центральный алгоритм. Одним из наиболее трудоёмких алгоритмов к реализации в движке Doom он называет определение видимости по лучу в лабиринте карты, в то время как параллакс неба называет весьма простой штукой. Ну и напоследок высказывается (как со стороны журналиста так и Кармака) пренебрежение к Full-Motion-Video играм (виртуальным тирам) и Кармак прямо говорит, что до тех пор пока Nintendo не прекратит бегать со своей ханженской моралью вряд ли что-то от id software появится еще на их консолях (отсылка к тому, что в Wolf3D пришлось убрать свастики).
P.S.
Ах, да. Doom на Atari Jaguar получился всё-таки мыльноватым, хотя фпс нормальный для того времени:
Некоторые результаты теста производительности при рендеринге 3DO
Около 3 недель назад меня зацепил другой бессмысленный проект по 3DO. Это не полный проект, а не эксперимент. Также моя любовь к игре Daggerfall. Мне просто нужно было посмотреть, могу ли я загрузить данные карты Daggerfall и заставить игрока перемещаться по любому месту в мире Daggerfall, и возможно ли это при полуприличной частоте кадров в 3DO. Этот проект еще не завершен, так как у меня есть только примеры того, как я нажимал на пиксель карты и рендерил область достаточно далеко, а не глазами игрока. Каждый четырехугольник, который я рендерил в приведенной выше ссылке на твиттер, составляет около 164 квадратных метров, и я должен быть намного ближе и разделять геометрию больше, чтобы получить точный масштаб Даггерфолла.
Это проект, который я продолжу в ближайшее время, просто он тем временем дал мне возможность провести несколько тестов производительности на реальной машине и получить некоторые цифры, которые мне были интересны. Одно из этих чисел, в котором пытались достичь теоретического предела количества полигонов в секунду, было опубликовано в моем последнем твите . Конечно, когда я использую ЦП для преобразования многоугольников (и, возможно, я смогу оптимизировать или научиться использовать предполагаемое аппаратное обеспечение матрицы машины, если я узнаю, как или, возможно, API-интерфейс математического портфолио его использует), геометрия из 2916 квадратов падает. до 5 кадров в секунду. Но при нажатии клавиши я пропускаю вычисление следующего преобразования, но продолжаю посылать уже преобразованный список четырехугольников из последнего кадра снова и снова. Таким образом, я тестирую исключительно пределы чистого снабжения оборудования полигонами, возможно, имитируя то, как маркетинг старых консолей будет требовать тысячи или миллионы полигонов в секунду (числа, которые вы никогда не увидите в игре, даже если вы разделили их с 30 или 60, чтобы получить приблизительное число за 30 или 60 кадров в секунду). Они никогда не говорят о реальных полигонах, которые вы ожидаете увидеть в играх, что будет намного меньше. Но, тем не менее, такой тест - хорошая идея того, чего ожидать, если бы вы были богом оптимизации, вы бы знали, что вы все равно не сможете преодолеть эти цифры или даже половину из них. Будучи консервативным, возможно, вы бы поделили эти числа на 4 или 8, чтобы получить некоторое приблизительное представление о том, что может быть практическим фокусом на сложности сцен.
Мне было действительно интересно все это, и я стремлюсь к тому, чтобы что-то делать и тестировать на реальном оборудовании. Я достиг некоторых теоретических максимумов, которые я слышал в прошлом, таким образом. Вы обычно пытаетесь проверить идеальные условия. Маленькие полигоны, плоские нетекстурированные, я получил чуть более 50 кадров в секунду, это около 150000 в секунду, что является точным числом, которое я постоянно слышал в интернете. С текстурами (и маленькими, 8 * 8, размер действительно имеет значение) я упал до 90000 (возможно, я тоже где-то слышал это число). Это еще не конец, я хочу сделать более надежный тест. Я понял, что небольшой процент полигонов (но, может быть, 5-10%) может быть немного скрыт за экраном, и у меня включено аппаратное отсечение, в то время как другие могут быть отодвинуты сзади, а настройки CW / CCW могут отменить рендеринг. еще один небольшой процент. Я подготовлю более надежный тест, в котором я разделю 2d-экраны на более детализированную сетку, всегда смотря прямо на игрока, как 2d-спрайты. Это следующий тест, который я хочу сделать. И я сделаю это таким образом, чтобы проверить как низкую пропускную способность, так и скорость чистого заполнения.
Но это не то, почему я открыл этот пост. Я сделал еще несколько тестов, которые я не опубликовал, которые имеют отношение исключительно к fillrate. Я также попробовал несколько новых методов более эффективной прокрутки большой 2D-карты. Перед 3D-рендерингом мне пришлось загрузить карту низкого разрешения (1000 * 500 пикселей), которая позже была разделена на 5 * 5 субпикселей (что делает ее 5000 * 2500, но эти субпиксели должны будут передаваться с CD каждый раз, когда я нажимаю на пиксель). на нижней карте 2D). И я бы прокрутил его так, чтобы игрок мог выбрать пиксель для отображения в 3D (он действительно выбирал область 3 * 3 таких пикселей, разделенную на 14 * 14 квадратов (линия сетки состоит из 3 * 5 вершин, но Вы должны вычесть один, так как они соответствуют 14 квадроциклам), это для простых тестов, но, конечно, для теста квадратов 2916, это были квадроциклы 11 * 11 и 54 * 54). И даже прокрутка этого большого растрового изображения стала проблемой производительности, грубой силы, которую я делал сначала. Это было неплохо, но ему не хватало полных 50-60 кадров в секунду (здесь я получаю 50 на моем PAL 3DO).
Проще говоря, я создал CEL с размером 1000 * 500 16-битных пикселей (и это близко к пределу, поскольку из того, что я прочитал в документации, максимальная ширина или высота текстуры, которую может принять графический процессор, должна составлять 1024). Обычный экран - часть этого, 320 * 240 * 16bpp. Итак, я бы просто отобразил это как спрайт (с моим кодом вы определяете объект спрайта с позицией, масштабированием, вращением (хотя нам не нужны последние два) и подготавливаете объект CEL с необходимыми векторами для его отображения) и позвольте аппаратному обеспечению управлять, когда большая часть CEL находится за пределами экрана.
Есть еще одно интересное узкое место в 3DO - тот факт, что CEL не будут очень эффективно прижиматься к экрану, как это делает современный графический процессор. Прежде всего, ловушка заключается в том, что когда вы запускаете новый проект 3DO, по умолчанию суперциклирование (как оно называется) графического процессора отключено. И хотя CEL содержат флаги, в которых путем изменения битов вы можете включать или отключать различные вещи, и доступны два флага для отсечения (отсечение CEL и линейное отсечение), в моем первом тесте я включил бы это, и ничего не изменилось бы в производительности. Это факт, который я знал задолго до проведения этого эксперимента, в старом коде, где я увеличивал масштаб некоторых 3D-звезд (на самом деле 2D-билборды), и когда некоторые из них становились очень закрытыми, но, возможно, за рамками, так что это было неочевидно, я получит огромные капли кадра. Я обнаружил, что вам нужно не только включить две супер-функции отсечения во флагах каждого из ваших CEL (каждый спрайт - это один объект CEL). Но сначала вы должны помнить, когда вы запускаете BitmapItems вашего видеобуфера в начале вашего кода, чтобы установить некоторые элементы управления движком CEL, например, включить функциональность суперклипа для всех, вызвав SetCEControl (BitmapItems , 0xffffffff, ASCALL);
Теперь, если вы этого не сделаете, моя прокручиваемая карта 1000 * 500 с огромными количествами, выходящими из экрана, будет чертовски медленной. И это было не так. Но все же что-то было выключено. И я знал причину раньше тоже. Когда я начинаю свой тест с положением, прибитым в верхнем левом углу карты (это означает, что большая часть текстуры за пределами границ будет выходить за пределы экрана справа и снизу), я получил более 50 кадров в секунду (при отключении vsync оно достигло 60). Но при прокрутке карты вправо я получил 25. При прокрутке вниз, чтобы достичь правого нижнего угла (чтобы большая часть моего растрового изображения была бы вне экрана с левой и верхней сторон), я получил 33. Теперь я понимаю, что 25 но все еще немного озадачен 33 (из-за моего понимания того, как он работает и как я задаю направление вектора для этого спрайта, я бы ожидал, что 25 и 33 будут изменены, но в любом случае это требует дальнейшего изучения). И причина в том, что отсечение графического процессора не просто решает геометрически найти меньшую область подкадра, где нужно начать рендеринг, но и обходит горизонтальный растеризатор для каждой строки (или, возможно, строит сетку) и каждый раз решает, следует ли прекратить рендеринг. превентивно. Например, если я рендерим горизонтальную линию развертки текстуры от X = 0 до 1000 с направлением вправо, каждый раз, когда я проверяю, я все еще являюсь кадровым буфером, а когда мне больше 319, я говорю «Так как мой вектор направления направлен вправо, и моя текущая позиция уже находится за пределами кадрового буфера с правой стороны, продолжения нет, поэтому давайте пропустим и перейдем к следующей строке " . Но если бы я выполнял рендеринг от -680 до 319, каждый раз, когда я находился с левой стороны вне кадрового буфера, я бы сказал: «Да, возможно, я нахожусь снаружи в течение большого количества пикселей, но, поскольку мое направление переходит к Правильно, я не могу предсказать, попаду ли я когда-нибудь в фреймбуфер, поэтому мне нельзя останавливаться ». , Насколько я знаю, ваша линия сканирования может быть от -1000 до -1, но это будет тратить время, поскольку графический процессор не будет геометрически вычислять границы и пропускать ранее из того, что я понимаю до сих пор. Могло бы быть частичное отсечение (которое все равно будет быстрее, чем полное отсутствие отсечения) и отсутствие рендеринга снаружи, но все равно проходящий процесс, которого можно избежать, найдя меньшую подходящую область. Мое понимание исходит из раздела CEL Clipping по этой ссылке .
Но в моей последней версии моего проекта я подумал о гораздо лучшем и более простом способе, где вы можете заставить CEL только читать и визуализировать указанную область гораздо большей текстуры. В некоторых флагах CEL есть два числа для горизонтальной ширины. Они установлены в некоторых флагах, называемых преамбулой . Одним из чисел (или действительно определенных битов на флагах) является точное количество пикселей в строке растрового изображения CEL (я установил это значение 320 вместо первоначальной 1000). Другое число также влияет на ширину и определяет, сколько слов минус 2, чтобы пропустить растровые данные для перехода к следующей строке. Таким образом, я мог бы установить, что это соответствует 1000 пикселей (500-2 = 498, поскольку пиксели 16 бит = 2 байта, 1000 шорт (16 бит) 500 длин (32 бита)). Это немного сложно и немного возиться и читать руководства, пока вы не получите его. И теперь я отрисовываю 320 * 240 пикселей из большого растрового изображения и никогда снаружи. Но, конечно, есть и другие проблемы, такие как прокрутка? Вы изменяете начальный адрес растрового изображения. Но это dword (32bit) выровненный. Таким образом, в 16-битной текстуре вы будете прокручивать каждые 2 пикселя по горизонтали, но по вертикали вы можете иметь плавную прокрутку как минимум. Однако, комбинируя некоторые другие флаги CEL, такие как SKIPX (я узнал об этом из оригинального кода рендеринга столбцов Doom 3DO), вы можете смещать на пиксель (вы должны самостоятельно исправить, уменьшив ширину текстуры между 320 и 219 с модулем над смещением X) и комбинируя все это, вы добиваетесь идеальной прокрутки (или выбора области точного подтекста 320 * 240, отображаемого на экране 320 * 240).
Так или иначе, я достиг этого, и вот здесь я начал еще один тест производительности, который мне был любопытен. Каковы ограничения скорости заполнения на этой машине? Чего ожидать от 2D игр? Кажется, это не так быстро, но не так уж и плохо, и с большим количеством оптимизаций и тщательного отбора вы можете многого добиться. Итак, каковы некоторые результаты?
В этом у меня был идеальный простой тест для точного считывания растрового изображения с разрешением 320 * 240 * 16bpp и рендеринга на экран с разрешением 320 * 200 * 16bpp. Одно полноэкранное чтение и одно полноэкранное запись. Я получал бы 85 кадров в секунду (независимо от того, где я прокрутил текстуру, нет дисперсии, так как больше не требуется суперскрепление). Это выше целевого fps (50 на 60), если мы хотим vsync для идеальной плавной синхронизации. Это хорошо. Но, конечно, если бы у нас была параллаксная игра с тяжелыми слоями, возможно, все стало бы проблематично. Но так ли это?
Обычно 2-й / 3-й параллаксные слои не будут полноэкранными пикселями, они будут иметь прозрачные промежутки в большинстве растровых изображений, что значительно оптимизировано с помощью 3DO. Так что, если вы не делаете глупостей и оптимизируете их с точки зрения графического дизайна, вы можете достичь гораздо большего. Во-вторых, моя текстура 16-битная, но, как я поняла, можно добиться большего, если ваша графика будет соответствовать 8-битной или менее. текстура CEL может иметь размер 1, 2, 4, 6, 8 или 16 бит. Итак, я попробовал один и тот же эксперимент с разной битовой глубиной. Я тестировал 8- битный -16- битный Uncoded (это чистый RGB) и 4-битный-6-битный 8-битный код (именно так в руководствах и API 3DO называют форматы текстур на основе индексированной палитры). Вот мои результаты.
16 бит - 85 кадров в секунду 8 бит - 113 кадров в секунду 6 бит - 129 кадров в секунду 4 бита - 148 кадров в секунду
Это не совсем линейно (но вы можете построить линию, которая подходит), так как 8-битные не в два раза больше, чем 16-битные, но также у нас более тяжелый рендеринг для 16-битной видеограммы. Я мог бы сказать, смогу ли я составить простое уравнение для прогнозирования, когда узнаю больше из своих тестов. Другое дело, что здесь нет никакой разницы между 8-битной версией Coded (paletized) и Uncoded (обе на самом деле со скоростью 113fps), но я читал где-то в руководстве. Coded может быть предпочтительнее в тех случаях, когда у вас есть прозрачные пиксели (индексный цвет 0 вместо сплошной цвет, чтобы пропустить рендеринг, может быть легче проверить, чем RGB 0,0,0 (который действительно становится прозрачным)?). В будущем у нас будет больше возможностей для оптимизации, есть даже формат текстур со сжатием RLE, который, я думаю, может пропустить большие прозрачные линии пикселей. Таким образом, это действительно зависит от того, какие форматы текстур вы используете, и вы должны быть стратегически настроены между уменьшением глубины цвета настолько, насколько ваше искусство выглядит не слишком плохо.
Еще одна вещь. Я хотел попробовать чистый рендеринг и очень мало чтения текстур. Первоначальный тест считывал данные размером 320 * 240 * 16bpp и записывал столько же данных. Что делать, если я наложил очень крошечную текстуру 4 * 4 * 16bpp и увеличил ее (чтобы она не была 4 * 4 пикселя на экране, а соответствовала экрану). Это будет в основном измерять чистую запись в производительность vram с минимальными потерями при чтении текстур. И вот что я попробовал. Результат был 239fps !
И еще один тест. Знаете ли вы, что в GPU есть не один, а CEL-движок. Другими словами, есть два параллельных процессора, и из некоторого чтения, которое я сделал, и из более поздних экспериментов, кажется, что рендеринг разделен между нечетным и четным линиями сканирования растрового изображения текстуры. Механизм 1 CEL позаботится о строках битовой карты 0, 2, 4, 8 и т. Д., А механизм 2 CEL будет работать с 1, 3, 5, 7 и т. Д. В CEL есть флаг, который сообщит ему, является ли каждый механизм CEL ждет, пока другие закончат свою работу или позволят им работать независимо. Есть также еще один флаг, который отключит и только один из двух сделает всю работу. К счастью, в отличие от суперклипа, эта функция двух параллельных движков по умолчанию включена, когда вы создаете ячейки, вызывая функцию API (но если бы вы должны были кормить биты самостоятельно, вы бы не забыли об этом), так что это Труднее быть ошеломленным и неэффективным, потому что API высокого уровня не сделал этого за вас.
Текстура 4 * 4, отображаемая на экране, менялась с 239 кадров в секунду до 133 кадров в секунду, если я отключил один из двух движков CEL. В обычных тестах (16, 8, 6, 4 бита) я получил числа 60, 82, 90 и 99fps . Еще одна странная вещь. Когда я включил двойные CEL-движки обратно в мой код, я неожиданно получил немного лучший fps. Я получил 89, 129, 143 и 163 кадра в секунду. Это немного важно. Но почему? Вот кикер. Я включил флаг, который на самом деле говорит "заблокировать два угловых двигателя вместе" . Но ждать? По умолчанию для этого было позволить им работать независимо. Что заставило бы меня задуматься: если один заканчивает (я полагаю, это одна из строк развертки), другой не ждет. Я ожидал бы немного увеличить, но не уменьшить, не связывая их вместе. Но что я знаю о том, как аппаратно работает глубоко? И это работает по-разному для меньших размеров полигонов или других условий? Это требует дополнительного расследования. (Вы можете посмотреть некоторые из этих флагов CEL здесь )
Я наконец проверил DMA. Другая часть оборудования называется SPORT . И это то, что я использую в настоящее время, чтобы стереть vram каждый кадр с цветом фона. В какой-то момент я подумал, что если это займет время, так как в моей стандартной структуре я всегда стирал кадр с этим переносом, прежде чем что-то рендерить, и здесь у меня была карта падения кинжала, стирающая ее каждый раз для меня, так что, возможно, это было ненужным. Насколько я знаю, это может быть и съедать часть частоты кадров. Но нет! Это полезный бесплатный для функции производительности. Я тестировал только вызов этого (полностью отключил рендеринг карты падения кинжала, просто пусть этот очистит экран). Я получил 1198fps ! Затем я тоже удалил этот файл (ничего не отображается, кроме моего крошечного счетчика кадров в секунду) и получил 1593 кадра в секунду. Если он не будет отображаться при рендеринге карты кинжала, это, конечно же, не повлияет на 85 кадр / с (иногда скачки между 84 и 85, но в любом случае это происходит). Итак, если вы хотите очистить экран перед следующим рендерингом, не делайте этого, как я делал раньше, рендерив большой черный CEL на экране, но вместо этого используйте SPORT DMA.
И последнее: если я хорошо понимаю (и мне нужно написать код и протестировать его), СПОРТ можно использовать еще для одной вещи. Вы можете рендерить статический фон из другого буфера в vram. Таким образом, вместо простой очистки одним цветом, вы можете очистить статический фон, который не двигается. Вы могли бы иметь, например, хорошую картину космических галактик и туманностей или чего-то еще, что не могло бы прокручиваться. Но это будет ваш статический фоновый слой, а затем вы можете добавить параллакс впереди. Вы не можете прокручивать, если я хорошо понимаю, но вы можете перетаскивать либо цветное, либо полноэкранное 16-битное статическое изображение. Во-вторых, я не знаю, как быстро это будет (возможно, потому что это SPORT DMA, это будет также что-то бесплатно, что вы можете использовать вместо подходящего Quad CEL, который будет тратить много). Я обязательно проверю в будущем.
Если кто-то удачно объединит все эти вещи (и, возможно, даже больше, что я смог бы найти), у вас в руках будет великая сила, возможно, у вас будут хорошие 2-мерные слои параллакса и много спрайтов, иногда масштабирование / вращение, если вы знаете аппаратное обеспечение и умны с ограничениями и вашим искусством. Но, конечно, это также очень легко испортить, если вы грубо насилуетесь и ничего об этом не думаете. Что произойдет в современном оборудовании, где так просто не думать об этом, а иногда это приведет к тому, что очень модные инди все еще не справляются со своей задачей. Независимо от того, насколько быстро система, вы всегда можете попасть в ловушку. В 3DO это более интересно, потому что это слишком просто, и в то же время есть отличная функциональность и классные обходные пути, чтобы получить эту прекрасную частоту кадров.
PS Не связано, но я купил 3DO мышь. Кто-то дал мне идею, могу ли я поддержать это в OptiDoom, хотя я даже не знал, что это существует. Это было бы весело и довольно легко попробовать, я думаю, по крайней мере!
pps я забыл упомянуть еще одну очень интересную вещь. Когда я делал свою демонстрацию STNICCC и в последних версиях преобразовал ее в эталонный тест, я заметил, что в некоторых тестах между текстурированным и нетекстурированным большим многоугольником у нетекстурированных многоугольников скорость была немного хуже, чем у текстурированных с очень маленькими размерами текстур. Я был как, как это возможно? Причина была в том, что обоим параллельным процессорам CEL потребовалось бы более одной строки растрового изображения для совместной работы. Исходные значения CEL для плоского рендеринга (как взято из Doom), исходя из того, что, как я понимаю, имеют размер текстуры 1 * 1 (но, возможно, также поставили некоторые флаги неуверенно и придется исследовать, потому что позже мне нужно дать нулевой указатель на источник и 16-битный цвет на указатель палитры, странно), и это не будет разделено пополам между двумя процессорами. Делая одноцветную текстуру на крошечной текстуре (например, 4 * 4 или даже 1 * 2 будет работать), вы заставляете процессоры по-настоящему разделить работу пополам для больших нетекстурированных одноцветных полигонов. Вот почему мой нынешний тест использует 4 * 4 (также 4 * 16 бит - 8 байт, минимальный размер для ширины текстуры в флагах, и у меня есть веские причины иметь n * n текстуру, а не n * m, хотя это бесполезно в этом тесте но это не имеет значения, результаты не изменились бы, но кое-что еще я обнаружил, что заставляет меня предпочитать n * n несколько раз, я буду говорить в будущем)
Сообщение от Оптимус в 19:33 Метки: 2d , 3DO , daggerfall , оптимизация , производительность , программирование , прокрутка
Да, интересно. Переводить как следует - лень. Cel-движок - имеется в иду CEL Engine - аппаратный графический ускоритель 3DO.
2916 прямоугольных полигонов - это он излишне разогнался, конечно, тем более, используя CPU. Вон, выше Naughty Dog пишут, что еле выжали из Sony Playstation - 1800 штук, и то ужасно извращаясь - пряча отображаемые полигоны за поворотами и за углами игровой карты, чтобы сразу не отображались и т.д. Иначе Crash Bandicoot начинал нещадно тупить.
А он на 3DO аж сразу на 2916 штук размахнулся.
Хотя то, что он возится с PAL-системой (он, судя по всему, англичанин) - это очень хорошо. Думаю, то, что он сделает, на NTSC будет себя вести ещё лучше.
27 окт 2019, 22:21
SavitarSvit
Ломаю джойстик взглядом
Группа: Пользователи Сообщения: 706 Регистрация: 13 сен 2017, 18:17
Модель 3DO:Panasonic FZ-10 NTSC-U
2916 прямоугольных полигонов - это он излишне разогнался, конечно, тем более, используя CPU. Вон, выше Naughty Dog пишут, что еле выжали из Sony Playstation - 1800 штук, и то ужасно извращаясь - пряча отображаемые полигоны за поворотами и за углами игровой карты, чтобы сразу не отображались и т.д. Иначе Crash Bandicoot начинал нещадно тупить.
Я так понимаю это лимит, но с какой скоростью все это будет работать - это уже не так важно. Вот доказательства от этого же автора:
Блог им. aa-dav Atari Jaguar — консоль пятого поколения, вышла в 1993 году почти одновременно с 3DO Interactive Multiplayer, но как и последняя проиграла гонку вооружений Playstation 1, которая появится годом позже........
На базе данной статьи выделил основную техническую составляющую Ягуара, отсекая ''лишнюю'' инфу для разработчика
Конструктивно можно выделить в консоли 3 главных чипа:
-Центральный процессор Motorola 68000 первого поколения, имеющий смешанную разрядность 16/32. 16-разрядное АЛУ 16-бит шина данных 24-битная шина адресов к памяти Тактовая частота 13.3 MHz.
-Графический чип «Том», который является многокомпонентной системой и состоит из:
Процессора объектов (Object processor) — это единственное в системе 64-битное вычислительное ядро, которое не программируется. Именно он формирует изображение на экране. Цветность может быть 16-битной (RGB или CMY(k)) или 24-битной (True Color). Выделенного буфера кадра нет, (видео памяти, как на 3DO) потому что таким буфером кадра без ограничений может быть произвольный регион памяти.
Графического процессора (GPU - graphics processor unit) — программируемый 32-битный RISC-процессор — в документации он называется GPU. Графический процессор является 32-битным RISC-процессором с выделенными 4Кб памяти кеша (доступная также остальным компонентам системы). Основная цель поставленная перед этим ядром была — скорость. Всё ради скорости и в то же время внутренней простоты. Имел некоторые аппаратные ошибки в работе..например, загрузку в него программ и данных в собственный кеш лучше проводить через процессор Блиттер, а не через DMA контроллер, в противном случае замедлялась вся работа в целом системы из-за возникающих внутренних конфликтов..
Блиттера (Blitter) — Это вспомогательный блок для графического процессора, способный быстро переносить блоки пикселей из одного места памяти в другое с некоторой их обработкой. Предполагается, что графический процессор должен заниматься вычислением вершин и характеристик графических примитивов, а блиттер — рисовать их пиксели. Блиттер способен:
* копировать блоки памяти * копировать и заливать прямоугольники * рисовать линии * вращать и масштабировать изображения * рисовать горизонтальные линии пикселей затенённых по Гуро полигонов с Z-буфером Не поддерживал текстурирование, закрашивая полигоны однотонным цветом. Тем не менее игры с текстурированием были, но в этом случае игра уже не использовала аппаратный Блиттер.
-Звуковой Чип «Джерри» занимающийся звукомю Является также является многокомпонентной сложной системой с таймерами, DMA-контроллерами, звуковыми каналами, серийными интерфейсами, портами ввода от джойстиков, но главной его компонентой является почти такой же RISC-процессор как GPU, только больше заточенный под обработку звука и называемый DSP. Это почти такой же процессор как GPU, но больше заточенный под обработку звука. Изменения включают в себя: — увеличенный до 8Кб объём внутренней памяти — 2Кб ROM-таблиц для синтеза звука (синусоиды, треугольные формы и т.п.) — увеличенная точность аппаратного умножения — несколько дополнительных инструкций для упрощения типовых задач работы со звуком
Консоль имеет 16-мегабайтное адресное пространство для 2 Мб основной памяти, 6 Мб ROM картриджа и многочисленных порты ввода-вывода. 2 Мб основной памяти (RAM) имеет довольно сложное внутренее устройство и разводку по шинам. К ней могут с разной степенью ограничений обращаться почти все компоненты системы, поэтому там создана довольно сложная система правил взаимных блокировок и распределения по разрядностям и шинам. Так, например, ЦП m68k может обращаться к памяти только 16-битными считываниями/записями максимум за один такт. Но тот же чип «Том» может обращаться к большей части памяти как к 64-битным значениям (с другой стороны к некоторым, выделенным областям — только как к 32-битным). С одной стороны возможность адресовать память чипом «Том» 64-битными значениями позиционирует консоли как 64-битную систему, но с другой стороны ЦП может с ней обращаться только как 16-битный процессор.
В целом консоль «изнутри» произвела впечатление больше аккуратности, чем тот же 3DO, но более сложной для разработчика (т.к. самому надо писать программы для рисования трёхмерной графики на GPU), в отличие от Playstation 1. Кармак весьма нахваливал консоль и даже выразился о ней как о лучшей игровой платформе на тот момент времени. Он подтверждал, что основной процессор m68k слишком медленный, но дополнительные RISC-ядра — это сила! Несмотря на то, что он сперва был недоволен тем, что Atari пытаются разработать собственные RISC-процессоры, но в итоге он нашёл их довольно быстрыми и хорошими в разработке — единственный минус — малый объём кеш памяти. Ну и то, что в них есть аппаратные баги... но самая значимая ошибка которую, по его мнению, совершила Atari — это то, что в качестве ЦП в консоли стоит устаревший, но разогнанный m68k. RISC-ядра по его мнению в 20 раз работают быстрее. Предварительно, любопытства ради, портировал сначало движок Wolf 3D со SNES на Atari Jaguar, после чего и сам Doom, но Кармак признавал, что Jaguar'y не удастся добиться плавности в 30 фпс какую Doom имел на процессоре класса Pentium.
28 окт 2019, 15:39
sasha 5
Добрый модератор
Группа: Модераторы Сообщения: 2321 Регистрация: 04 дек 2009, 11:58 Откуда: Новосибирск
Модель 3DO:Panasonic FZ-10 NTSC-U
геометрия из 2916 квадратов падает. до 5 кадров в секунду.
Я так понимаю, что это максимум теоритических (нетекстурированых и в не игровых условиях) полигонов, которые можно ''выжать'' одним цп без матричного сопроцессора (поскольку автор не знал как его задействовать на тот момент). С другой стороны в игровых условиях, даже если использовать матричный для геометрии, (который побольше бы сгенерировал чистых кватратов, чем цп) реальная полигональная производительность очень мала..ну сколько можно максимум дать? 100, 200...500 полигонов на игровой сцене
Те кто читал внимательно предыдущую статью про архитектуру Atari Jaguar могли заметить, что описывая блиттер консоли были упомянуты и затенение по Гуро и Z-буфер, но ничего не было сказано про текстурирование. И это действительно так — блиттер не умел текстурирование вообще
Ох лол у снес фх-чипы и то текстурировали
30 окт 2019, 03:59
ross_nikitin
Супермодератор
Группа: Супермодераторы Сообщения: 7987 Регистрация: 04 дек 2009, 12:31 Откуда: Германия, г.Кобленц
Модель 3DO:Panasonic FZ-10 NTSC-J
Максимум детализации у модели что я видел сделанного для ягуара. Хотя задних фонов нет, кажется даже чуть подтормаживает. Такое в игре вряд ли возможно, если только на 2D заднике.
Jag Lion - By Tursi
Вот пожалуй хороший пример, игра полностью без текстур. Такое пожалуй лучше всего подходило.
Club Drive (Jaguar) Playthrough - NintendoComplete
03 мар 2020, 23:19
ross_nikitin
Супермодератор
Группа: Супермодераторы Сообщения: 7987 Регистрация: 04 дек 2009, 12:31 Откуда: Германия, г.Кобленц
Модель 3DO:Panasonic FZ-10 NTSC-J
Начал проходить пару дней назад на планшете классику Planescape Torment, слышал что угра очень длинная, решил узнать сколько в средней требуется часов на прохождение. Полез в гугл, кинуло мне ссылку на https://cubiq.ru/gametime/, зашел, посмотрел, не думал что такие ресурсы по играм занимаются вот такими вещами. В Planescape Torment, для неторопливого, досконального изучения игры, требуется примерно 82 часа, будем посмотреть. Правда поиск игр бестолковый, требует очень точного правописания, нельзя выбирать по алфавиту, на главной странице не нашел как туда перейти. Посмотрел потом Shadow Man, для досконального прохождения всего 26 часов? Что то тут не вяжется, хотя я время тогда не засекал, но по ощущениям было куда больше, не говоря о новой версии где были добавлены доп. локации. Из плюсов это пожалуй большое количество игр, вся классика вроде есть, даже на денди. Кажется даже онлайн игры есть, и дополнения к играм тоже. Сейчас подумал, походу они как то прогами считают время прохождения или с ресурса какого нибудь тянут, но идея интересная.