Войти
ФлеймФорумЖелезо

Блеск и нищета 32/64-битных консолей и ПК (4 стр)

Страницы: 13 4 5 68 Следующая »
#45
20:41, 6 ноя. 2017

=A=L=X=

Я как-то заводил тему про ПС2 и ее игрули, в частности, на что способен был EE в отсутствии аппаратной поддержки того, что вводилось с каждым поколением новых видях на РС. Конечно самым пиком был Shadow of Colossus, который дал картинку нереальную до ужаса.

UPD?> Нашел тему. http://www.gamedev.ru/flame/forum/?id=86134 . Только видосы давно мертвые  :(


#46
7:10, 7 ноя. 2017

Playstation 2

Главный чип PS2, в котором находится центральный процессор и несколько сопроцессоров, называется Emotion Engine (EE).
Растеризатор полигонов находится в другом чипе - Graphic Synthesizer (GS) и одна из основных задач EE - накормить GS списком команд для отрисовки через 256-байтную FIFO-очередь команд (GIF).
Основные компоненты EE: центральный процессор (ЦП), векторные процессоры VPU0 и VPU1, декодер MPEG2, 10-канальный DMA-контроллер, системная шина на которой сидят 32 Мб основной RAM и прочие таймеры и порты ввода-вывода.

Центральный процессор
ЦП - 64-битный MIPS R5900 (MIPS III + ограниченная поддержка MIPS IV) на 299 МГц, кроме того добавлены кастомные целочисленные 128-битные SIMD-команды, причём для последних были увеличены до 128 бит (в норме 64-битные) регистры общего назначения MIPS III, что было "видно" только этим командам.
Имеет 16 Кб кеша инструкций, 8 Кб кеша данных и 16 Кб сверхбыстрой "scratchpad RAM". Последняя фактически была реализована по той же технологии, что и кеш, но прямо отображалась в адреса RAM, что даже позволяло использовать её в передачах DMA, так что она крайне рекомендовалась, как буфер для интенсивной обработки данных процессором.
ЦП так же имеет урезанный сопроцессор с плавающей точкой, которого лишили 64-битной точности (double), поэтому обрабатывать он может только 32-битные float-ы, а кроме этого он не поддерживает NaN и +/-Inf, так что его даже нельзя считать IEEE 754-совместимым.
В качестве еще одного сопроцессора к ЦП подключен блок векторых вычислений (VU) от VPU0, так что в норме VPU0 отключен, а его векторным блоком пользуется ЦП исполняя свой поток команд. Однако VPU0 может быть включен как самостоятельный процессор и тогда ЦП должен избегать пользоваться его векторными регистрами и командами.

VPU0 и VPU1
Каждый из VPU обладает 16-битным целочисленным ядром (шестнадцать 16-битных регистров общего назначения) для выполнения команд в собственном выделенном для себя банке памяти и векторным модулем (VU) осуществляющим операции над банком из 32-ух регистров хранящих четвёрки 32-битных float-ов (x,y,z,w).
Через DMA они могут получать/отдавать данные другим компонентам системы. Система команд у них LIW (long instruction word) повышенной параллельности - в 8 байтах кодируется две 4-байтных полукоманды, одна всегда работает с векторным модулем, другая же или с ним или со скалярными вещами.
VPU0 имеет всего 4Кб памяти программ и 4Кб памяти данных (пламенный привет RSP из N64!), VPU1 же имеет по 16Кб того и другого.
VPU1 всегда работает как самостоятельный процессор, а вот VPU0 может переходить в режим подчинения ЦП как сопроцессор - при этом некий усеченный набор команд ему даёт уже ЦП. Но даже в таком режиме ЦП может дать VPU0 команду CALL и тогда его ядро "проснётся", чтобы выполнить подпрограмму в собственном адресном пространстве и снова "уснуть". Кроме того ЦП может давать VPU0 команды LOAD/STORE для доступа к его памяти данных, так что 2x4Кб продолжают оставаться крайне полезными даже тут - VPU0 выступает не просто как сопроцессор, но сопроцессор с программами и данными, которые можно обновлять на лету.
VPU1 имеет дополнительно скалярный блок работы с 32-битными float-ами с экспоненциальными и тригонометрическими функциями для более гибкой обработки данных.
А главное - VPU1 напрямую подсоединён к FIFO-буферу GIF через который данные отправляются в видеочип GS. У VPU1 просто есть машинная команда засылающая 128-битный блок из его памяти данных в GIF.
В принципе данные в GIF может засылать и ЦП - уже посредством DMA-контроллера.
Вообще VPU подключены к системной шине через VIF (Vpu InterFace) - контроллеры достаточно сложные, принимающие-отдающие данные организованные в блоки команд/пакетов. VIF принимает, например, такие команды как "залить данные", "залить код", "запустить код", "дождаться выполнения кода", а так же способен распаковывать поступающие в VPU данные на лету - например распаковывать цвет в формате 1:5:5:5 в четверку float-ов, чтобы VU смог легко считать их потом из внутренней памяти VPU одной векторной командой.
Крайне интересной особенностью PS2 является то, что и VPU1 и ЦП+VPU0 могут засылать команды в GIF/GS одновременно! GIF заранее устроен как бы двухканальным на ввод - с одного (приоритетного) канала он принимает команды от VPU1, а с другого - то что присылается ему по шине через DMA (процессором).

Взаимодействие ЦП, VPU и GPU
И вот сказанное только что и отражает заложенную в пайплайн PS2 изначально разработчиками концепцию оптимального рендера.
По их генеральному плану ЦП должен был брать под свой контроль блок VU от VPU0, чтобы расширять свою систему команд блочной обработкой _необычных_ вершинных данных, которые требуют особого подхода и много логических переходов.
Я думаю понятно, что сюда попадает всякая скелетная анимация, развевающиеся на ветру флаги и всякое такое прочее.
Предполагалочь, что VPU1 в это самое время, вооруженный более крупными 2x16 килобайтами внутренней памяти, обрабатывает простые, массивные и блочные данные - например статичные массивы вершин под матрицами - стены лабиринта и так далее.
И первое и второе скармливались в GS _одновременно_. Вы спросите - а как же глобальные стейты между разными моделями? Если между командами отрисовки уровня от VU1 вдруг вклинивается команда отрисовки треугольника модели от ЦП+VU0, то что произойдёт, ведь у лабиринта и модели, очевидно, разные текстуры?
Так вот - GS отслеживал и понимал из какого из двух каналов данных пришла очередная команда и внутри себя хранил два независимых набора параметров рендера (render state)! Один брался когда приходили команды от VPU1, а другой - когда приходили команды от ЦП/VPU0 (из общей шины)!
Вот и весь фокус - переключение между этими двумя render-state-ами было абсолютно дешевым, скорее всего просто коммутация линий каких то внутренних шин данных, поэтому GS действительно мог безболезннено получать одновременно два независимых потока команд на отрисовку.

Разумеется разработчиков никто не заставлял рендерить всегда именно так - программно рендер мог быть настроен как угодно. Можно было вообще не пользоваться VPU и отправлять команды только процессором.
Можно было "отсоединить" VPU0 от процессора и всё-таки загрузить что-нибудь самостоятельное в его 4 Кб памяти инструкций (у Nintendo 64 с его RSP с точно такими же объёмами кода и данных же получалось!).
Можно было парой ЦП+VPU0 подгатавливать в предыдущем кадре "динамическую порцию" вершинных данных, а на следующем кадре просто линковать их с общим потоком данных для VPU1. И так далее...
Но основным запланированным режимом была параллельная подпитка GS из ЦП+VU0 командами "сложной" геометрии, в то время как из VU1 тут же лилась "простая/блочная" геометрия.

В общем как видно T&L в PS2 был навороченным и наскипидаренным синтезом подходов виденных нами ранее и в PS1 и в Nintendo 64.
В эту копилку еще надо добавить "цепочечный режим передачи DMA", который сильно расширяет способность DMA-канала в PS1 заливать в порт растеризатора данные в формате однонаправленного связного списка.
В PS2 аналогичный формат "связного списка" для DMA-передач уже имеет заголовок с типом текущего блока - и это один из 8 (восьми!) вариантов того как располагаются и что означают поля HEADER/DATA/NEXT. Например в одном варианте данные располагаются сразу после HEADER, а указатель NEXT указывает на следующий HEADER. В другом же формате данные лежат по адресу в NEXT, а следующий HEADER располагается сразу после текущего. При этом еще есть связь с подсписками - типы узлов CALL/RET, для создания древовидной структуры. Кроме того два DMA-канала могут быть завязаны в автоматический кольцевой буфер, когда один из них пишет в основную RAM, а другой из неё читает - такое называется MFIFO (Memory FIFO).

#47
7:10, 7 ноя. 2017


Graphic Synthesizer (GS)
GS является растеризатором уже прошедших T&L вершин.
Основные его возможности:
- обработка цвета в 32-битном RGBA
- рисование точек, линий, ломанных линий (line strips), треугольников, лент и полос из треугольников (triangle strips and fans), спрайтов
- заливка по Гуро
- текстуры с перспективной коррекцией и билинейным или трилинейным сглаживанием
- как 16/24/32-битные тестуры с прямым указанием цвета так и 4/8-битные текстуры с указанием цвета через CLUT (Color LookUp Table)
- Z-буфер с тремя возможными глубинами: 16, 24 или 32 бит
- альфаблендинг, антиалиасинг, попиксельный туман, обрезка по прямоугольнику (scissors), stencil
- 2 рендер-стейта (уже должно быть понятно почему)
Видеочип имеет 4 Мб выделенной Video RAM (VRAM) в которой в любом месте располагаются фреймбуфер, Z-буфер, текстуры и CLUT.
Кроме того у него есть банк 64-битных регистров с номерами от 0x00 до 0x62. Часть из них, представляющих render-state при отрисовке примитивов, существуют в двух копиях того самого переключаемого контекста. Некоторые представляют вещи не связанные с render-state-ом, например для инициации передачи битмапов между основной памятью и VRAM (в обоих направлениях) нужно произвести запись в определенные регистры, выставив параметры передачи и инициировав её. И еще одно подмножество регистров олицетворяет текущий рисуемый примитив - есть регистр его координат (фиксированная точка 12:4), текстурные и Z-координаты (следует понимать, что в GS всё это отправляется уже в экранных координатах - screenspace), рассчитанный цвет RGBA и т.п.
Часть регистров называются "привелигированными" и доступны для чтения/записи в адресном пространстве ЦП, это самые глобальные параметры - видеорежим, место в VRAM где лежит отображаемое на экране изображение и его формат и т.п. Но большая часть регистров доступна только через GIF.
VU1 и ЦП отправляют в GS через контроллер GIF команды в специальном формате. В сущности команды эти выполняют операции записи в регистры видеочипа.
В связи с тем, что данные в памяти VU как правило разложены в четверки 32-битных float (x,y,z,w), а VU1 рассматривается как основной поставщик команд, то и формат данных для GIF прогибается под это.
Итак, команды в GS заходят пачками/пакетами, предваряемые 16-байтным (128-битным) заголовком, хранящим количество и назначение последющих 16-байтных блоков.
Форматы этих пакетов столь замысловаты, что я их тут заколебаюсь описывать, поэтому я просто констатирую, что есть разные форматы передачи данных в регистры GPU: как универсальные так и уплотнённые "запакованные", особенно что касается передачи данных в регистры атрибутов и вершин примитива, но в целом суть сводится всегда к записи какого то значения в какой то регистр видеочипа.
Ключевым моментом для отрисовки примитивов является то, что ряд регистров описывает как бы атрибуты текущей вершины примитива, запись в них обновляет информацию о текущей вершине - типе примитива в который она входит, её цвете, текстурных координатах и т.п. и при этом запись в регистры содержащие информацию о сообственно координатах (XYZ) приводит к "проталкиванию" вершины во внутренний буфер примитивов, который GS и отрисовывает как только поступают новые данные заканчивающие описание примитива. Для треугольника нужно 3 точки, для стрипов - 2 затравочных начальных и каждая следующая генерирует новый треугольник и так далее.
Другими словами этот чип растеризации явно что-то знает про glBegin/glVertex/glEnd и чует моё сердце, что его ноги растут из одного, всем известного API. :) Хотя это не факт, но тем не менее.

Заключение

Вот и всё, что можно сказать обзорно-архитектурного про PS2 и её графический пайплайн. Машина получилась на удивление продуманной и замысловатой - количество всяческих форматов и контроллеров эти форматы разбирающие и гоняющие данные в них туда-сюда зашкаливает.
Emotion Engine получился довольно мощным переосмыслением идей T&L, которые мы видели как в PS1 так и в N64, причём со своими фишками и рюшечками, спаренными и неспаренными дополнительными процессорами, выделенными ОЗУ, шинами и кодерами/декодерами форматов.
Я уже не помню когда T&L появился в домашних видеокартах, но однозначно, что имея всё это на рынке годами просто невозможно было не прийти к тому же и в персоналках, благо PS2 побила и держит до сих пор рекород по количеству проданных консолей.

#48
11:30, 7 ноя. 2017

=A=L=X=
> Другими словами этот чип растеризации явно что-то знает про
> glBegin/glVertex/glEnd и чует моё сердце, что его ноги растут из одного, всем
> известного API. :)

конечно, откуда есть пошла 3d графика :)

#49
22:57, 7 ноя. 2017

=A=L=X=
> - как 16/24/32-битные тестуры с прямым указанием цвета так и 4/8-битные
> текстуры с указанием цвета через CLUT (Color LookUp Table)

полноцветные(или обычные) 16/24/32-битные тестуры и индексированные(палитровые) 4/8-битные

#50
5:56, 8 ноя. 2017

Освежил, кстати, память - ндааа... Как я уже говорил T&L в виде чётко специализированного сопроцессора появился в PS1 в 1994-ом году, а в 1996-ом он присутствовал в Nintendo 64 уже в виде независимого процессора (RSP) - с собственной памятью команд и данных и системой команд с обточкой под T&L. В PS2 всё было совсем уже сложно - были и процессор и сопроцессор для T&L и разветвленная система скармливания растеризатору данных после T&L. При этом на деле дату выхода первой консоли с T&L возможно надо сдвинуть на год ранее - в 1993-ий, ведь до PS1 вышла еще 3DO у которой оно возможно тоже есть, судя по поверхностному описанию в вики.
А что в это время творилось на ПК?
А ПК обзавелись аппаратным T&L в видеокартах только в 1999-ом году с появлением GeForce 256 и D3D 7. Можно было бы вспомнить про опять таки сопроцессоры - ведь были же, были, эти вот MMX, 3DNow! и SSE? Ну да. Только MMX было целочисленной штукой и для матричных операций - не айс, 3DNow! появилось только в 1998-ом, а SSE - в 1999-ом, то есть уже в тот же год когда T&L начал проникать на рынок. В общем да, затянутость имеет место быть.

Не ну понятно, что где-то на адски дорогих станциях Silicon Graphics что-то такое было и в более бородатые годы, но я говорю про домашний рынок. Сосноли тут не только не консули, но и совсем даже наоборот.

#51
6:27, 8 ноя. 2017

=A=L=X=
> Сосноли тут не только не консули, но и совсем даже наоборот.

сравнил массовый комп и спец железку

#52
7:08, 8 ноя. 2017

innuendo
> сравнил массовый комп и спец железку

Ну в наше время эти спец-железки выходят на 3-4 года устаревшими по сравнению с ПК которые может купить каждый.

#53
8:48, 8 ноя. 2017

=A=L=X=
> Ну в наше время эти спец-железки выходят на 3-4 года устаревшими по сравнению с
> ПК которые может купить каждый.

зато там прямой доступ к железу и миллиард батчей в секунду :)

#54
12:22, 8 ноя. 2017

Запилил и в этой теме и в теме про 8/16 бит оглавления в первопостах с которых легко можно найти блоки с полезной инфой в самих обсуждениях.
Если что-то хотите сами сюда запостить и внести в оглавление - пишите.

#55
10:50, 11 ноя. 2017

3DO - консоль опередившая своё время. У нас она слабо известна да и конкурентную борьбу она быстро слила.
Тем не менее замечательна она тем, что она вышла первой в пятом поколении - первой посягнула на рубежи полноценного 3D.
Поэтому я не смог обойти её вниманием - и не прогадал! Технологическая "замшелость" девайса - то что я ожидал от первого 32-битного поколения, но не нашёл ни в PS1 ни в N64.
И вот оно!

Интересна консоль была еще несколькими моментами. Подробно можно прочитать на вики. Но я и тут сделаю краткий очерк.
Во первых - правообладатель консоли, The 3DO Company, не имел собственных мощностей и связей, поэтому разработал её и предложил всем желающим производить за роялти.
Всего было 3 активных производителя консоли, из которых Panasonic стал наиболее часто с ней ассоциироваться, поэтому её часто неправильно называют Panasonic 3DO. На самом деле Panasonic 3DO - это лишь конкретная и только одна из реализаций общей технологической спецификации 3DO Interactive Multiplayer.

Вышла первая консоль в США в сентябре 1993 года - то есть за пару месяцев до релиза Doom 1. И в ней действительно был упрощающий отображение 3D аппаратный растеризатор, как того требовало от приличных машин поколение.
Так что окунёмся на несколько минут в графические реалии 3DO, посмотрим что это был за зверь...

#56
11:01, 11 ноя. 2017

3DO Interactive Multiplayer

Центральным процессором (ЦП) в 3DO был 32-битный ARM (ядро ARM60, семейство ARM6, архитектура ARMv3) на частоте 12,5 МГц. Это еще без кэша и многостадийных конвееров. Тем не менее архитектура RISC требует осмотрительно сравнивать частоты с другими процессорами - утверждается, что он обладает эквивалентной производительностю m68k на частоте 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 ( кстати, скачать эту документацию можно тут: http://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 - из двух разных, с буферизацией.

#57
11:02, 11 ноя. 2017

Cel Engine

Главное что в 3DO есть от "3D" - это конечно же растеризатор, или, как он тут называется - Cel Engine. Почему то фрагменты изображения растеризуемые им называются тут Cel-ами.
И что характерно - Cel-ы довольно сильно отклоняются от привычных нам ныне способов рендера и растеризации.
Растёт идея Cel Engine как бы из отрисовки обычной 2D-графики - главная его функция заключается в копировании прямоугольного куска изображения из некоего битмапа-источника в некий битмап-приёмник. Возможно они оба должны располагаться в VRAM, но это не точно.
Давайте для начала рассмотрим какие возможности Cel Engine даёт для копирования прямоугольного куска изображения, то есть блиттинга, а потом одним приёмом перейдём к 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 коэффициентов с фиксированной запятой можно настроить произвольные афинно-перспективные трансформации, которые будут применяться к битмапу источника при растеризации.
Наглядно это можно себе представить как произвольную возможность задавать вершины четырёхугольника назначения в битмапе-приёмнике.
Лучше один раз посмотреть на картинку, чтобы понять:

Изображение

В центре изображен "прямоугольный" перенос, самый простой и быстрый, по краям же изображено несколько примеров как можно произвольно "перетаскивать" и "перекручивать" углы уже четырёхугольника в битмапе-приёмнике.
Во главе всего по прежнему стоит прямоугольник. При этом важно заметить, что его координаты в источнике могут быть только прямоугольником с ортовыровненными сторонами - здесь нет аналогии с текстурными координатами в привычных нам методах растеризации полигонов.
Вообще сам алгоритм растеризации тут "вырвернут наизнанку". Это можно было заметить уже по тому, что битмап источника может быть запакован.
На самом деле что здесь всегда происходит - Cel Engine линейно слева-направо, сверху-вниз обходит по порядку пиксели битмапа-источника и проецирует их в битмап-приёмника.
Не наоборот, как делают современные рендеры, которые пляшут от пикселей треугольника спроецированного уже на фрембуфер - выполняя пиксельные шейдеры и текстурные выборки по одному разу для каждого пикселя во фреймбуфере.
Cel Engine в 3DO пляшет от пикселей источника и проецирует их один за одним в приёмник - эта процедура выполняется ровно 1 раз для каждого (непрозрачного) пикселя в источнике.
Этому есть еще два свидетельства - во первых в ЧАВО по быстродействию прямо говорится, что уменьшение картинки при растеризации не ускоряет значительно рендер. То есть копирование картинки без изменения размера и копирование картинки с уменьшением размера во фреймбуфере хоть до 1 пикселя занимает почти что одинаковое время!
Второй момент касается увеличения картинки при масштабировании - существует флаг "быстрого копирования", который может приемлемо себя повести если картинка сохраняет размеры или уменьшается, но даст пропуски (вплоть до гигантских) между пикселями, если картинка увеличивается. Это может быть использовано даже как спецэффект. На деле документация прямо говорит, что при масштабирвании с увеличением Cel Engine тщательно анализирует блоки пикселей в приёмнике которые надо залить одним и тем же пикселем источника и запускает для них двойной цикл этой заливки - это замедляет процедуры и именно это поведение и отключает флаг "быстрого копирования".
Еще один момент, связанный с поддержкой 3D есть в том, что консоль понимает порядок отрисовки "по часовой" и "против часовой", может отбрасывать отрисовку того или иного, причём корректно обрабатывая смену направления при самопересечении четырёхугольника.
Но больше никакой поддержки 3D в 3DO нет - ни Z-буфера, ничего другого.

Заключение

Вот такой "допотопный" и я бы даже сказал, что неопытный подход к рендеру был у 3DO. Как видно он явно растёт из блиттинга изображений, далее видимо пройдя через блиттинг с масштабированием и вращением эволюционирал в нечто с 3D-потенциалом, но с ограниченными возможностями в плане выбора текстурных координат.
Вообще консоль действительно оставляет чёткое послевкусие неопытности: то борьбы с ветряными мельницами, то отсутствия понимания в какую сторону надо двигать 3D-рендер.
Playstation 1 была объективно лучше, современнее и адекватнее потребностям рынка, на что ей хватило год и пары месяцев форы.

#58
20:31, 11 ноя. 2017

=A=L=X=
> Центральным процессором (ЦП) в 3DO был 32-битный ARM (ядро ARM60, семейство
> ARM6, архитектура ARMv3) на частоте 12,5 МГц. Это еще без кэша и многостадийных
> конвееров. Тем не менее архитектура RISC требует осмотрительно сравнивать
> частоты с другими процессорами - утверждается, что он обладает эквивалентной
> производительностю m68k на частоте 25 МГц

сам как думаешь, почему так?

#59
20:41, 11 ноя. 2017

innuendo
> сам как думаешь, почему так?

Зачем думать, я читал про всё это давно и много. :)

Страницы: 13 4 5 68 Следующая »
ФлеймФорумЖелезо