Такой вот, вероятно, глупый вопрос назрел
Играю сейчас и что-то приуныла. Неужели, у Сатурна не хватило бы мощности под обратную совместимость? В нем же есть 16-битный цпу (сопроцессор). А ещё представьте - сколько доп.возможностей сразу открывалось бы! И, потенциально, запуск SMD\Gen и 32Х (с дисков бы приспособили запускать) шикарный получился бы сега-комбайн, аж 4 в 1!
Чё не? Дискасс ит
Добавлено спустя 2 минуты:
Полагаю, всё упиралось в замудренную архитектуру и сложности программирования под эти цпу... а маньяков-программистов еще надо поискать... Так себе идея.
Так вроде в момент выхода Сатурна, Sega CD еще вполне себе была жива и на нее продолжали выпускать новые игры, так что в этой совместимости, ИМХО, не было столь большой необходимости как в случае, скажем, с Saturn <-> Dreamcast. Да и сам факт наличия этой приблуды нужно было чем-то оправдывать. А то владельцев обычных 16-битных Сег и так фактически кинули после покупки 32Х (практически оставив без игр для оной), а если бы сделали нечто подобное в случае с CD (поддержку которого запилили бы в Сатурн), то это была бы вообще подстава для фанатов СМД.
Ну что тут скажешь. Такие времена тогда были. Все фичи реализовывались в железе а не програмно. Тогда, как и сейчас, все стоило денег и времени. Снес например умела и нес и гейм бой через переходники. Сама сега умела cd через переходник, смс вроде тоже.
Если выпускать поддержку аддона для Мега драйва, то тогда нужно запилить поддержку и самого мегадрайва. Как то логично это. Только никак не вяжется с абсолютно новой консолью от СЕГА. К тому же железная часть удорожила бы и без того дорогую консоль, на фоне конкурентов. Писать же эмулятор под новую архитектуру сатурна было то еще занятие. К тому же неизвестно какой получился бы конечный результат.
В общем решение вполне себе логичное, особенно при переходе на новый формат. Да и 94 год на дворе тогда был в Японии. Нужно было и Sega CD еще продавать.
PS. Вот если бы Сега не наложали с 32х и отмененной " 32х и мегадрайв в одном корпусе" , а сразу все силы кинули бы на сатурн. Что бы без двух процессоров "как у 3do" (который провалился в продажах), еще бы и с поддержкой картриджей от мегадрайва через слот расширения. То тогда да - сказка. И Playstation и Nintendo 64 оказались бы не у дел 100%. Несмотря на более дорогую цену на старте. Сеге тогда бы доверяли и ждали продолжений полюбившихся серий.
Я думаю хотели уйти и забыть все эти аддоны мегасд и 32х, сосредоточившись на абсолютно новой консоли. И складские остатки немалые этих адднонов нужно было распродавать, а их поддержка в сатурне этому бы явно не способствовала.
Sega CD сама по себе уже является "комбайном", потому что некисло расширяет возможности обычного мегадрайва - там и новый быстрый процессор и всякие прочие фички, поэтому тащить пришлось бы слишком много всего. К тому же у 16-битных консолей процессор это треть дела, а вот картинку рисует видеочип и он там некислый по сложности, а еще чип синтеза звука. На 32 битах всё это было бы исключительно ради обратной совместимости, ибо принципы и графики и звука полностью сменили парадигму. В итоге "обратная совместимость" просто превратилась бы в консоль внутри консоли, что ударило бы по цене без существенных выгод, все уже сели в поезд под названием "переезд в 3Д".
Почитал вчера что из себя представлял 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-битных консолях было слоем спрайтов в отдельный фреймбуфер чтобы в него можно было рендерить четырёхгольные спрайты произвольных трансформаций:
http://altmer.arts-union.ru/3DO/docs/DevDocs/ppgfldr/ggsfldr/gpgfldr/figures/G.3-2.gif
И из этих спрайтов и надо было формировать по настоящему трёхмерную графику. Слои же задних (и передних) фонов остались как были в старых консолях и в принципе могли быть использованы для вывода задних фонов в привычных платформерах, но в полноценном 3D их применение было существенно более ограниченным - панельки с игровой информацией разве что, да пол-потолок в чём нибудь типа Wolf3D (т.е. монотонная плоскость уходящая в закат)...
Ну и подход с четырёхугольными спрайтами потом логично вымер, т.к. обладал рядом существенных недостатков.
Спасибо! Очень интересная инфа по Сатурну!
Немного еще посмотрел в то как именно работают палетризированные цвета в 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 этому посвящена всего одна строчка (мой перевод):