[ Каскадный ] · Стандартный · Линейный Почему Сатурн не научили?, Читать SEGA-CD

[Iris]

Такой вот, вероятно, глупый вопрос назрел

Играю сейчас и что-то приуныла. Неужели, у Сатурна не хватило бы мощности под обратную совместимость? В нем же есть 16-битный цпу (сопроцессор). А ещё представьте - сколько доп.возможностей сразу открывалось бы! И, потенциально, запуск SMD\Gen и 32Х (с дисков бы приспособили запускать) шикарный получился бы сега-комбайн, аж 4 в 1!

Чё не? Дискасс ит

Добавлено спустя 2 минуты:
Полагаю, всё упиралось в замудренную архитектуру и сложности программирования под эти цпу... а маньяков-программистов еще надо поискать... Так себе идея.

Сообщение отредактировал Iris - Суббота, 13 апреля 2019, 14:25

[aa-dav]

Почитал вчера что из себя представлял Saturn с точки зрения программиста: https://segaretro.org/images/1/16/13-APR-94.pdf

Довольно забавная штучка первого поколения 3D и так же как и 3DO базовым элементом сделавшая не треугольник, а четырёхугольник.
Терминология тоже в силу молодости индустрии весьма непривычная, так эти четырёхугольники даже с 3Д и освещением по Гуро они продолжают называть спрайтами.
Нафаршировали систему с каким то даже остервенением.
Два 32-битных RISC-процессора Hitachi SH-2 делят общие 1,5 Мб рабочей памяти.
Предполагается что второй из них выполняет всякие вспомогательные штуки типа трансформации вершин, но при этом узким местом является доступ к рабочей памяти. Поэтому у процессоров было по 4Кб кеша которые во втором переведены в режим 2Кб кеша + 2Кб сверхбыстрой памяти.
Но кроме основных процессоров программированию так же поддавался SCU (System Control Unit) - этот модуль разводил данные по шинам системы, содержал DMA-контроллер и DSP гарвардской архитектуры с модулями умножения, в который можно было загружать небольшие программы которые могли опять таки решать задачу умножения на матрицы с одновременной перегонкой данных из рабочей памяти в видеочипы по DMA.
Еще был 4-битный микроконтроллер Hitachi сидящий на таймере и задачах генерации прерываний и опроса данных от периферии (например геймпадов). Он работает всегда и питается от батареи когда системы выключена, видимо через него консоль включается/выключается.
Подсистема CD-ROM-а содержит собственный процессор SH-1 и 0,5 Мб памяти под буфера ввода. Программировать его нельзя, общение происходит посредством заранее обозначенных команд. Например можно было заставить его закешировать какой либо файл для быстрой подкачки.
Звуковая система содержала 32-канальный генератор PCM или FM-звуков, которые подают свой сигнал в особый DSP на 128 инструкций, которые могут делать массу преобразований с этими звуками и в довесок еще работает всё это под управлением опять таки программируемого микроконтроллера 68EC000 (упрощенная версия m68k) который по умолчанию был запрограммирован сегой как midi-секвенсер, но при необходимости его тоже можно было перепрограммировать.

Видеосистема состоит из двух видеочипов - VDP-1 и VDP-2. Каждый имеет выделенные 512Кб VRAM.
VDP-1 делит их пополам на два фреймбуфера по 256Кб. Пока рендерим в один буфер другой отображается на экране.
Отрисовка происходит скармливанием видеочипу связного списка команд к отрисовке. Геометрические примитивы называются "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. Вообще там есть еще какой то фарш типа разных масштабных коэффициентов для каждой строки слоя, но в подробности вчитываться было некогда.
В сущности Saturn действительно нафарширован и сложен в освоении чтобы в него еще обратную совместимость пихать.
Забавна сама архитектура переезда в 3D. Фактически они выделили то что в 16-битных консолях было слоем спрайтов в отдельный фреймбуфер чтобы в него можно было рендерить четырёхгольные спрайты произвольных трансформаций:



И из этих спрайтов и надо было формировать по настоящему трёхмерную графику. Слои же задних (и передних) фонов остались как были в старых консолях и в принципе могли быть использованы для вывода задних фонов в привычных платформерах, но в полноценном 3D их применение было существенно более ограниченным - панельки с игровой информацией разве что, да пол-потолок в чём нибудь типа Wolf3D (т.е. монотонная плоскость уходящая в закат)...
Ну и подход с четырёхугольными спрайтами потом логично вымер, т.к. обладал рядом существенных недостатков.

Сообщение отредактировал aa-dav - Среда, 17 апреля 2019, 07:34