1 ポイント 投稿者 GN⁺ 2024-03-28 | 1件のコメント | WhatsAppで共有
  • Sega Saturnは3D移行期に登場したコンソールだが、単一の3Dアクセラレータではなく、デュアルSH-2 CPUとSCU、VDP1・VDP2、独立したオーディオ・CDサブシステムを組み合わせた並列構造で設計されている
  • CPUは約28.63MHzのHitachi SH-2を2基master-slave構成で配置したが、外部バスを共有するため性能が単純に2倍になるわけではなく、開発難度も高かった
  • グラフィックスではVDP1が四角形ベースのスプライトをフレームバッファに描画し、VDP2が背景・平面・レイヤー合成を担当するため2Dには強かったが、3Dでは可視面判定や半透明処理の制約が大きかった
  • オーディオはSCSP/Yamaha YMF292、Motorola 68EC000、512KBのサウンドRAMで構成され、独立したコンピュータに近く、CD-ROMのおかげでPCMサンプルやCD-DAベースの高品質サウンドトラックを活用できた
  • CDコピー対策としてSegaは標準CD領域外のリングとCDドライブ内部のSH-1検証を用いたが、その後mod chip、swap trick、PseudoSaturn、Satiator、ODEのような回避・ホームブルー実行方式が登場した

3D移行期の複雑なコンソール設計

  • Mega Drive以後のSega Saturnは、3Dのみを強制するのではなく、必要に応じてポリゴン描画を支援できるよう複数のハードウェア要素を組み合わせたコンソールである
  • 全体の回路は多数のプロセッサと4つの主要サブシステムに分かれる
    • CPUサブシステム: メインCPU、メモリ、SCUが配置される
    • Videoサブシステム: グラフィックスアクセラレータが配置される
    • Audioサブシステム: 独立したコンピュータに近いオーディオ処理構造を持つ
    • CD-ROMサブシステム: コピー防止メカニズムのため閉鎖的な構造を持つ
  • 各サブシステムは専用バスに接続され、VideoとAudioサブシステムは1本のバスを共有する

CPU: 2基のSH-2とSCU

  • Segaは次世代ゲームと3D機能のために、HitachiのSuperH系CPUを選択した
  • SuperHは組み込み用途を念頭に置いたCPUだったが、当時のRISC系設計要素を含んでいた
    • load-storeアーキテクチャによりメモリ演算とレジスタ演算を分離する
    • 32ビットデータバスと32ビットALUを備える
    • 16本の32ビット汎用レジスタを備える
    • 32ビットアドレスバスにより最大4GBのメモリアドレス指定が可能
    • 5段パイプラインで複数命令を段階的に処理する
    • 初期のSuperHには16ビット乗算ユニットが搭載されていた
  • SuperH ISAはRISC設計でありながら、すべての命令が16ビット幅である
    • CPUは32ビット単位で命令をフェッチするため、1サイクルで2命令を取得できる
    • この方式はRISCアーキテクチャのコード密度問題を緩和する
  • RISC設計特有の制約も残っている
    • 制御ハザードのため、プログラムはbranch delay slotを考慮する必要がある
    • SuperHはdelay slotを含むdelayed branch instructionsを提供する
    • データハザードは、CPUが必要時にパイプラインを自動停止して処理する

SH-2の選定とデュアルCPU構成

  • Segaは16ビット乗算器が3Dゲームの大量データ処理でボトルネックになり得ると判断し、Hitachiに改善を求めた
  • Hitachiは乗算ユニットを拡張し、Segaの要件を反映したSH-2を作った
  • 競合コンソールのCPU選定を意識したSegaはクロック向上も望んだが、製造段階のチップでクロックを上げることは不可能だった
  • HitachiはSHの研究段階で、複数のSHが同一システム内で同時動作できるよう最小限の回路を追加しており、SegaはSaturnに2チップ構成を採用した
  • 最終的なCPU構成は、並列処理の可能性とボトルネックを同時に抱えていた
    • Hitachi SH-2を2基、それぞれ約28.63MHzで動作させる
    • 2基のCPUは物理的には同一だが、master-slave状態で配置される
    • master CPUはslave CPUに命令を送ることができる
    • 同じ外部バスを共有するため、バス競合が発生しうる
  • SH7604チップには実行性能を補強するための機能が含まれる
    • 5段パイプラインと拡張されたSuperH ISA
    • 32ビット乗算ユニット
    • 共有される32ビット外部データバス
    • 4KBキャッシュ
    • 32ビット除算ユニット
    • 内蔵DMAコントローラ
    • little endian対応
  • CPUが2基あるからといってゲームが2倍速く動作するわけではなく、効率的な並列処理のためには共有バスとキャッシュ活用を考慮した複雑なプログラミングが必要になる

メモリとSCU

  • CPUサブシステムは汎用のWork RAM 2MBを備える
  • Work RAMは2つのブロックに分かれる
    • WRAM-H: 1MB SDRAMでアクセス速度が高く、バスは他の構成要素と共有される
    • WRAM-L: 1MB DRAMで速度は低いが、バスはメインCPU専用である
  • CPUグループには2基のSH-2に加えてSaturn Control Unit(SCU) も含まれる
  • SCUはデータ移動と計算補助を担う2つのモジュールで構成される
    • DMAコントローラ: CPU介入なしで3つのサブシステム間のWRAM-Lアクセスを仲介する
    • DSP: 固定小数点ジオメトリユニットのように使われ、3D変換やライティングなどの行列・ベクトル計算をSH-2より高速に実行する
  • SCU DSPは半分の速度で動作し、命令セットもより複雑で、データfetchとstoreに低速なWRAM-LとDMAを使う
  • SCUにはローカル用途向けの32KB SRAMが含まれる

グラフィックス構造: VDP1とVDP2

  • Saturnは異なる役割を同時に担う2つの独自GPU、VDP1VDP2を使用する
  • 3D世代のグラフィックス設計ではフレームバッファが重要になる
    • GPUがVRAMの一部にシーンのビットマップを描画し、その後ビデオエンコーダがそれを出力する
    • フレームバッファのサイズは画面解像度と色深度に比例する
    • 例として600KBのVRAMは640×480、32K色、16bppのフレームバッファを収容できる
  • Saturnのベクトル演算アクセラレーションはSH-2自体ではなくSCUが担当する

VDP1: 四角形ベースのスプライトとフレームバッファ

  • VDP1は幾何変換が適用されたスプライトを描画し、その結果をフレームバッファに書き込んだ後、VDP2に渡して表示する
  • プログラミングはdrawing commandsを発行する方式である
    • コマンド、テクスチャ・タイル、カラー・ルックアップテーブルなどを保存するために512KBの専用RAMを使用する
  • 基本図形は四角形 quadrilateralのみである
    • モデルは4頂点ポリゴン、すなわちスプライトで構成される
    • Forward Texture Mappingでテクスチャ点を四角形に対応付ける
    • フィルタリングや補間手法がないため、レンダリングにaliasingが生じる
  • 提供される効果にはFlat・Gouraudシェーディング、anti-aliasing、clipping、transparencyが含まれる
  • 256KBのフレームバッファチップを2個使い、片方のバッファを表示している間にもう片方へ次のシーンを描く
    • 2つ目のバッファのレンダリングが終わると表示バッファを切り替えるpage flippingを用いる

VDP2: 背景平面、レイヤー合成、透視補正

  • VDP2は最大4096×4096ピクセルの大型平面を回転・拡大縮小・移動変換してレンダリングすることに特化している
  • フレームバッファを持たず、CRTビームの進行に合わせてon the flyでレンダリングする
  • 最大1,670万色の24ビットカラーをサポートする
  • VDP1の出力バッファも表示でき、これを自身のレイヤーと変換・合成できる
  • フレーム構成は次のいずれかを選ぶ
    • 最大4つの2D平面と1つの3D平面
    • または2つの3D平面
  • VDP2はtile-mapで平面を構成し、3Dテクスチャマッピングにperspective correctionを適用する
  • 提供される効果にはmulti-texturingとshadowingが含まれる
    • VDP1から受け取ったスプライトの明るさを下げ、半透明にブレンドできる
    • ただしCRTビーム速度に合わせたスプライトストリームしか受け取れないため、エンコードと運用が難しい
  • VDP2にはVDP1のindexed colour値を24ビットRGBに変換するための4KB CRAMが含まれる
  • 3D平面は2枚に制限されるが、CPUがVDP2 VRAMをソフトウェアフレームバッファのように使って追加の2D・3Dグラフィックスを描くこともできる

2Dに強く、3Dに癖のあるグラフィックスマシン

  • Saturnの2Dシーン処理能力はMega DriveやSNESよりはるかに広かったが、コンソールの主なセールスポイントではなかった
  • 2DゲームではVDP1が従来型スプライトを描き、VDP2が背景平面を描いた後、自動合成して完成したシーンを作る
  • _Mega Man X4_ではVDP1がスプライト平面を担当し、VDP2が複数の背景平面を構成する
  • VDP2機能を使えば、スケーリング効果で陽炎のようなシーン効果を作れる
  • 3Dでは長所と難点が同時に現れる
    • 8個のプロセッサを活用できる余地はあったが、開発者は短い商業寿命の中で機能を習得しゲームを発売しなければならなかった
    • ゲーム品質はタイトルやスタジオごとのアプローチによって大きく異なった
  • Saturnは任意角度の4点四角形であるdistorted spritesを定義し、テクスチャマッピングで面を埋める
  • CPUとSCUが3D世界を構成して2D空間へ投影すると、VDP群がそれをレンダリングし、効果を適用したうえでTVへ出力する
  • どのVDPが中核レンダリングを担うかはゲームごとに異なった
    • 近距離ポリゴンをVDP1に任せ、遠景背景をVDP2に任せる開発者もいた
    • VDP2が近距離ポリゴンまで描くよう迂回手法を作った開発者もいた

可視面判定と半透明の制約

  • 3Dポリゴンを2D空間に投影する際には、カメラから見えるポリゴンと隠れるポリゴンを区別する必要がある
  • この問題はVisible Surface Determination(VSD) として知られ、モデル表示の正確さ・透明効果・ハードウェア資源使用に影響する
  • SaturnのVDP1はVSD機能を実装していない
    • ジオメトリを正しい順序で渡さなければ画面が破綻する可能性がある
  • SegaのグラフィックスライブラリSGLは、Z-sortすなわちPainter’s algorithmをソフトウェアで実装する
    • カメラからの距離に応じてポリゴンを遠いものから近いものへ並べ替える
    • その後、その順序でVDP1コマンドを発行する
  • Z-sortのZ-order値は近似値なので、3D環境ではグラフィックの不具合が依然として発生しうる
  • 一部のプログラマはSGLの代わりに独自アルゴリズムを実装した
  • Saturnは半透明グラフィックスをレンダリングできるが、制約が大きい
    • 半透明ピクセルのブレンドはVDP2だけが処理できる
    • VDP1は重なったスプライトを区別せずレンダリング済みバッファを出力するため、半透明スプライトが下のスプライトを隠してしまう
    • VDP1のforward texture mappingはdistorted spritesに半透明を適用する際に問題を起こす
    • 半透明ピクセルは描画に6倍の時間がかかる
  • 2Dゲームではtextureのmesh属性を使い、一部座標を完全透明にする方法で回避できる
    • composite video信号ではmeshパターンがぼやけ、半透明のように見える効果が生じる
    • この方法でも不透明部分が他のスプライトを隠す問題は残る
  • _Daytona_は半透明を無効化して背景が突然現れるように見え、_Sonic R_はVDP2のmix ratioレジスタとライティングレベル切り替えで半透明とfading効果を実現している

オーディオ: 独立したサウンドサブシステム

  • Saturnのオーディオ機能は、CD-ROMとサンプルシンセサイザが結びついた当時のデジタル移行の流れの中にある
  • サウンドサブシステムはSCSP/Yamaha YMF292、Motorola 68EC000、512KBのsound RAMで構成される
  • SCSPは2つのモジュールに分かれる
    • 多機能サウンドジェネレータ: 最大32チャンネルをPCMサンプルまたはFMチャンネルとして処理する
    • DSP: echo、reverb、chorusのようなオーディオ効果を適用する
    • PCMは最大16ビット、44.1kHzのCD品質サンプルをサポートする
  • Motorola 68EC000はオーディオ構成要素を制御し、メインCPUとインターフェースする
    • Saturnの68EC000は11.3MHzで動作し、16ビットバスで接続される
    • sound driverを実行して周辺モジュールを運用する
  • 512KBのsound RAMはsound driverやPCMサンプルのようなオーディオデータを保存し、DSP作業領域としても使われる
  • オーディオパイプラインはメインCPU、68EC000、SCU、CDサブシステムで分担される
    • メインCPUがオーディオ構成要素を初期化し、sound RAMにsound driverをロードする
    • その後Motorola 68EC000を有効化する
    • ゲーム中にはSCUがCDからsound RAMへPCMサンプルを転送できる
    • CDサブシステムはCD-DAの非圧縮オーディオをSCSPへ直接送ることができる
    • Video CDカードがあれば、圧縮オーディオをカード側でデコードしてからSCSPへ渡せる
  • CD-ROM採用とPCM処理能力のおかげで、スタジオはサウンドトラックを自前で録音・制作し、再編曲なしでゲームに収録できるようになった

ブート、IPL、内蔵シェル

  • 電源を入れると、まずSMPC(System Management and Peripheral Control) が動作する
  • SMPCは4ビットマイクロコントローラで、2基のSH-2の電源投入やmaster-slave構成の設定など、周辺チップの初期化を担当する
  • その後master SH-2のreset vectorは0x00000000に設定され、このアドレスは512KB ROMのInitial Program Loader(IPL)を指す
  • IPLはハードウェア初期化後、ブート対象を順に確認する
    • 実行コード入りのカートリッジがあれば、そこからブートを継続する
    • Video CDカードがあれば、それをブートする
    • ディスクがあれば正規品かどうかを検証する
    • 正規品ならゲームをブートする
    • 正規品でない、またはディスクがない場合はinteractive shellを実行する
  • Saturnにはゲーム以外にMultiplayerという内蔵音楽プレーヤーがある
    • ここからセーブデータ管理にアクセスできる
    • Video CDカードがあれば、カードがデコードしたMPEGビデオも再生できる
  • Saturn ROMはPlayStation BIOSのような開発者向けAPI群として主に使われるのではなく、IPLとして呼ばれる
  • ただしIPL ROMには、セーブデータ管理、電源制御、マルチプロセッサ同期用のsemaphoreなどのSystem programサービスも含まれる

ゲーム媒体と開発環境

  • 公式Saturnゲームは2x CD-ROMドライブからロードされる
  • 媒体はCompact Discのカスタム変種で、容量は650MB、ISO 9660標準に従う
  • 多くのゲームはデータトラックの横にオーディオトラックを含み、ゲーム中に非圧縮オーディオをストリーミングする
  • CDはpolycarbonate表面の微細なpitlandに情報を記録し、赤外線反射を読んでデータを復元する
  • CDは保存密度と同期のため、複数のエンコーディング・誤り訂正技法を用いる
    • NRZIはpit-land遷移時に1を記録する方式である
    • EFMは8ビット組を、CDリーダーの制約に適した14ビットシーケンスへ変換する
    • CIRCはデータをディスク全体に分散し、冗長性を追加して損傷領域の復旧を可能にする
  • SaturnはCD-ROM XA形式を採用する
    • データ、非圧縮オーディオ、interleaved multimedia tracksを保存できる
    • 低速ドライブでもオーディオと画像を妥当な速度でストリーミングするうえで重要である
    • 動画再生の伸張には別売りのVideo CDカードが必要である
  • 開発環境は初期には負担が大きかったが、その後ツールが強化された
    • Segaは十分なソフトウェアライブラリや開発ツールを提供しておらず、初期ドキュメントにも不正確な部分があった
    • 許容できる性能を出すには、初期にはアセンブリプログラミングが重要だった
    • その後SegaはSDK、ハードウェアキット、I/O・グラフィックス支援ライブラリを提供した
    • SaturnゲームはCと各構成要素向けアセンブリ言語を組み合わせて書かれた
  • I/OとRTC管理はSMPCが担当し、SH-2がコマンドを送って制御する

拡張インターフェース

  • Saturnには複数の外部コネクタとインターフェースがある
  • ドライブ背面のcartridge slotは、公式にはセーブデータ用の追加ストレージやextra RAM用途に使われる
    • 日本と米国では、オンライン接続用のmodemも提供された
  • 背面にはVideo CD Cardスロットがある
    • 対応ソフトやゲーム向けにMPEG伸張を行う
  • 背面のCommunication Connectorは、Segaが開発者向け文書を公開しなかったインターフェースである
    • リバースエンジニアリングの結果、SCSPのMIDIピンと2基のSH-2のSerial Interface(SCI)に接続されていることが確認された
    • Segaはこのインターフェースを使うfloppy driveを発売した

コピー防止とホームブルー実行

  • CDコピーが容易だったため、Segaはゲーム流通の制御に向けてコピー防止とregion lockingを実装した
  • Saturnのコピー防止は、標準CD形式から意図的に外れる方式である
    • 一般的なCD burnerではSaturnゲームの完全なコピーを作れない
    • Saturnのディスクリーダーは検証過程で非標準の特徴を探す
  • Saturnディスク外周の最外縁には異常なデータパターンがプレスされている
    • このパターンは商標ラベルが刻まれた可視リングを形成する
    • リングは標準データ領域であるProgram AreaとLead-outの外側にある
    • 一般的なドライブではこの領域にアクセスも複製もできない
  • Saturn CDドライブ内部には専用のSH-1プロセッサがあり、リングの有無をmain CPUとは独立して検証する
  • この検査は1回しか実行されない
  • 従来の回避方式はディスク検証過程を欺くことに焦点を当てていた
    • mod chipを取り付け、どのディスクが入ってもCDリーダーを騙す
    • swap trickで正規ディスク検証直後に焼いたディスクへ入れ替える
  • その後、より洗練されたホームブルー実行方式が登場した
    • PseudoSaturnはコピー防止メカニズムのexploitを使い、検証なしでディスクゲームをブートさせる
    • 2022年時点では、新しいforkであるPseudo Saturn Kaiが使われている
    • 2016年にはVideo CD add-onがCDドライブを迂回してCDサブシステムへ暗号化されていないコードを注入できる点を利用した方式が登場した
    • このVideo CD exploitはSatiatorという製品として販売されている
    • Optical Drive Emulator(ODE) はCDリーダーをSDまたはSATAアダプタに置き換え、SaturnにはCDを読んでいるように見せつつ、実際にはディスクイメージを読み込む

1件のコメント

 
GN⁺ 2024-03-28
Hacker Newsの意見
  • 記事ではチップ数が多いという形で、設計が驚くべきものだったかのように描いているが、文脈を見る必要がある。日本チームと米国チームの間にはシナジーがまったくなく、主導権争いがあった。
    SEGA JPは2Dコンソールを作っていて、SEGA USは3Dコンソールを作っていた。そして日本チームがその争いに勝とうとしていた瞬間にPSXが登場し、事実上その2つを合体させてしまったようなもの。
    結果として、未完成の3Dコンソールの部品が入った2Dコンソールになり、設計としては筋が通らない。
    技術好きや開発回顧を読むのが好きな人にとっては壮観だが、すっきりした設計を好む人にとっては際限なく気になる。
    あの時代の一般ゲーマーにとっての核心は「リビングの中のアーケード」だったが、Saturnは期待外れで、SEGAがどちらに集中すべきか分かっていなかったこともまったく助けにならなかった。
    Wikipediaの記事により詳しい内容がある: https://en.wikipedia.org/wiki/Sega_Saturn

    • これはおおむね間違っている。Saturnは完全にSega of Japanの設計だった。
      Saturnのハードウェア設計者インタビュー(https://mdshock.com/2020/06/16/hideki-sato-discussing-the-se...)を見ると、なぜそのようなハードウェア構成を選んだのかという視点が示されている。
      基本的に彼はPSXへの反応を見て3Dが未来だと分かっていたが、Virtua FighterやDaytona USAのような3Dアーケードゲームを作っていたSEGAのAM2チームを除けば、社内の専門性は伝統的な2Dスプライトベースのゲームにあった。
      そのため、2Dゲームに優れ、3Dもある程度可能なコンソールが最善の妥協だと見ていた。
      最大の失敗は、業界がどれほど速く3D中心へ移行するかを過小評価したことにあったと思う。
      実際のSEGAの内紛の結果は、もっとばかげたものだった。Sega of AmericaはGenesisの68000の後継であるMotorola 68020を使う、Saturnより保守的な設計を望んでいた。性能は低いが、開発者はそのハードウェアにより慣れていただろう。
      この争いに敗れた後、SOAはSaturnは価格が高すぎて米国では売りにくいと判断し、Genesis用の200ドルのアドオンである32Xを設計した。
      32XはSaturnと同じSH2プロセッサを使うが、グラフィックスはすべてソフトウェアで描画し、Genesisのグラフィックスの上に重ねて表示していた。
      当初の計画は、Saturnを2〜3年間日本専用にし、32Xを海外で販売することだった。
      Sega of Americaは32Xへの関心を集めるために巨額の資金を使い、社内開発も32Xだけに集中したが、開発者もメディアもSaturnに比べて32Xにはほとんど関心を示さなかった。
      32Xが市場を持ちこたえられないことが明らかになると、Sega of Americaは32Xから関心をそらすためにSaturnを急いで発売した。しかし、この1年を32Xタイトルの開発に費やしていたため、日本のゲームに頼らざるを得ず、その多くは米国市場に合っていなかった。
      32Xは発売タイトルよりキャンセルされたタイトルのほうが多く、このすべてが開発者と消費者を混乱させ、怒らせることになった。
    • 調べた限りでは、Saturnに3Dが遅れて追加されたという物語には欠陥があるように見える。
      VDP2が3D対応のために後から追加されたという話はよく引用されるが、VDP2は3Dをまったく行わず、SNESのMode 7風の背景レイヤーを担当する。
      VDP2を取り除いても、映像のスキャンアウトをVDPが担当している点を無視すれば、残るコンソールは依然として3Dをうまく扱える。
      実際、多くの3DゲームはVDP2をほとんど使っていない。
      2Dゲームは背景を数百個のスプライトでレンダリングしなければならないため品質面で損をするだろうが、可能ではある。
      逆にVDP1を取り除くと、VDP2の2D背景レイヤーだけが残る。
      すると3Dもなく、画面にスプライトも載せられないので、2Dゲームにも事実上役に立たない。
      見たところ、Saturnは最初からVDP1とVDP2の両方を持つことが意図され、両者が連携して動作するよう設計されていた。
      SEGA JPの意図は、最終設計に見られるように、限定的な3D能力を備えた2Dの怪物コンソールだったように思う。
      SEGA JPとSEGA USの間に議論がなかったという意味ではなく、その証拠はかなりあるように見える。
      ただし、最後の瞬間に日本の設計と米国の設計を混ぜ合わせたとは思わない。
      Saturnは日本でPSXより12日早く発売されているので、PSXがその議論に影響を与えたと見るのも難しい。
    • PlayStationとNintendo 64に関する別の記事を見ると、90年代に3D対応コンソールを設計することは、どの会社にとっても大きな挑戦だったことが分かる。
      だから各社がそれぞれ異なる解決策を提示し、長所と短所も異なっていたが、どれも分析して比較するには興味深い。
      この記事が書かれた理由もそこにある。
      https://www.copetti.org/writings/consoles/playstation/
      [https://www.copetti.org/writings/consoles/nintendo-64/](https://www.copetti.org/writings/consoles/nintendo-64/
    • 「あの時代の一般ゲーマーにとっての核心はリビングの中のアーケードで、期待外れだった」という言葉には例外がある。
      シューティングゲームのジャンルでは、Saturnには日本のシューティングゲームがあふれており、多くの作品が完全、またはほぼ完全なアーケード移植だった。
    • 優れたビデオゲーム史ポッドキャストThey Create Worldsの最新エピソード(https://www.theycreateworlds.com/listen)が、こうした神話の一部をうまく反証している。
  • Sega Saturn はかなり複雑なハードウェア構造を持っていた
    ゲームの「作業」を複数の CPU と専用プロセッサに分散してスケールさせるのが、費用対効果の観点で理にかなっていたのは理解できるが、これが Saturn の比較的低調な販売に影響したのだと思う
    結局、各社がそのハードウェアをきちんと活用するゲームを作るために、すべてを習得する投資を正当化しにくかった、という話はよく聞いた
    Sid Meier の「楽しむべきなのはゲーム開発者ではなくプレイヤーだ」という言葉を思い出すが、この場合はハードウェア設計者たちが楽しみすぎたのではないかと思う

    • 90年代に育ちながらSega の没落を見ていたのは奇妙だった
      こちらでは Mega Drive、つまり Genesis は SNES ほどではないにせよ、ほぼそれに近い成功を収めていて、誰もが Mega Drive を持っているか、友人の家で定期的に遊んでいた
      本当に人気のあるハードウェアだった
      ところが次の世代では誰もが Playstation を持っていて、Saturn を買った子はたった一人しか知らなかった
      こちらでは Saturn が Playstation より数か月早く発売されたことを考えると、本当に不思議だ
      当時 Saturn が劣った選択肢に見えたからなのか、価格や供給の問題だったのか、ほかの要因があったのかは分からないが、Playstation が完全に圧倒していた
      その後 Sega は姿を消した
    • 記憶では、費用対効果の問題ではなかった
      Saturn はビッグ3の中で製造コストが最も高く、PlayStation と価格を合わせなければならなかったことが Sega にとって財務上の災厄になった
  • 「したがって VDP1 は基本図形として四角形を使うよう設計されており、4つの頂点を持つポリゴン、つまりスプライトだけでモデルを構成できる」という部分のせいで、3D の Sega Saturn ゲームは PS1 版よりも角張った印象を与えていた
    Saturn 版と PS1 版の Resident Evil を並べて比較すると違いが分かりやすい
    全体として、Sega Saturn のゲームは90年代の 3D ゲームの中でも独特の美感を持つことになった
    また、Sega Saturn のエミュレーションが他のプラットフォームよりかなり遅れている点も指摘に値する
    西側での成功の低さと複雑な構造が相まっていたように思う

    • Saturn のエミュレーションは現時点ではかなり堅実だ
      ただ、長い間かなり貧弱だったのは確かだ
    • エミュレーションの最善の代替として FPGA がどこまで来ているのかは分からないが、コンソールを改造して、そのコンソール向けに発売された全ゲームを SD カードに入れて使うのが気楽だ
      本当に気に入っているタイトルは eBay でオリジナルのゲームを買って、支援している気分にもなれる
      オリジナルの価値を保つためにゴム手袋をしてプラスチックケースから CD を取り出し、毎回また戻すのは面倒すぎるが、オリジナルのゲーム体験をエミュレーションに置き換えたいわけではない
  • Sega Saturn には Panzer Dragoon Saga、Shining Force III、Burning Rangers、Dragon Force I & II のような隠れた名作がかなりあり、知る限り移植やリメイクはされていない
    もちろん Saturn Bomberman も外せない

    • フレームレートが悲惨だという点さえ無視すれば、Virtual Hydlide も忘れてはいけない
    • Panzer Dragoon は記憶が正しければ初代 Xbox に出ていた
      Saturn と、その後継である Dreamcast はかなり良く、もっと成功してもよかった
    • プラットフォームの複雑さが、ゲームが他へほとんど移植されなかったことに影響したのだと思う
      実際、私の知る限り Saturn と他プラットフォームの両方に存在するゲームは Saturn へ移植されたものだけで、その逆はなかった
      もし間違っていたら誰かが訂正してくれるかもしれないが
      理解している限り、Saturn のエミュレーションも今なお難しい部類で、この10年でかなりの進展はあった
  • 私が好きな Saturn の技術解析/ハッキング動画はこれだ
    https://www.youtube.com/watch?v=jOyfZex7B3E

  • コンソールの多様性を見て、PC が支配する前、家庭用コンピュータの栄光が暮れつつあった時代の多様性を思い出した
    同じ OEM やパブリッシャーの一部は今日まで生き残っている
    インフォグラフィックで見てみたいし、自分で作る気になるかもしれない

  • Copetti の仕事は好きで、以前引用して書いたこともあるが、いつもあまりに高レベルに感じる
    それでも、こういう文章を書くのにどれだけ多くの労力がかかるか分かるので、これ以上を求めるのはいつも不当な気がしてしまう

  • 結局のところ、宣伝と Sony の資金力が SEGA に勝った。本当にそれがすべてだ
    もちろん SEGA も自傷行為に近いミスをたくさんした
    ゲームで見ると、PSX で本当に世界を揺るがしたゲームは何だったのか? 1996年の Resident Evil と1997年の FFVII くらいか?
    Saturn にも、特に1996年にはキラーゲームがあったので、個人的にはライブラリの問題ではないと思う
    コーディングが難しいという点も、一世代後の開発者たちは Playstation 2 をうまく扱っていたし、Dreamcast は活用しやすかったが、SEGA が終息させると皆が見捨てた
    米国基準ではユーザーベースも悪くなかったし、欧州はよく分からない
    SEGA に対する消費者の好感度の問題もあるが、Sony や MS のシステムの信頼性問題を見ると、必ずしもそうとは言えない
    特に 360 はかなりひどかったが、コンソールの長期的な存続にはまったく打撃を与えなかった
    SEGA CD は少なくとも米国では失敗作ではなかった
    常にハイエンドで、やや不要ではあるが格好いい製品で、優れたゲームもあったがキラーアプリはなかった
    SEGA にとっては成功だった
    32X は関係者全員にとって巨大な失策だったのは確かだが、一般消費者レベルで、その短い存在だけで Saturn を単独で潰したとは思わない
    米国ではマーケティングさえうまくやれば人々は何でも買うと思う
    Saturn の米国マーケティングはひどかった
    SEGA は正気を取り戻せず、Genesis を SNES より成功させた要素をすべて捨ててしまった
    コンソールで何がうまくいき、何がうまくいかなかったかを技術や細部の面から語ることはできるが、実際にはマーケティングの失敗と、発売時にもその後にもまともな Sonic がなかったことが Saturn を潰した

    • PSX が、特に米国で Sega Saturn より優れたゲームライブラリを持っていたというのは、おおむね合意された評価と見て差し支えない
      1997年は FF7、FF Tactics、Tekken 3、Symphony of the Night など、ものすごい年だった
  • 良い分析。1996年から持っているオリジナルのSega Saturnを今も持っていて、ときどき思い出に浸るために電源を入れている。
    開封した日とまったく同じように、今でも完璧に動く。
    ハードウェア構造はかなり複雑になっていたのかもしれないが、昔のコンソールの信頼性は好きにならずにはいられない。
    ここ数年使ってきたもっと現代的なコンソールは、過熱したり別の形で故障したりしていて、同じことは言いにくい。

    • 古いコンソールだから信頼性が高いというだけではなく、SEGAとNintendoがそうだったということ。
      SonyとMSが参入してから、コンソールの信頼性ではすでにコスト削減が始まり、それが今の姿にまで至った。
      PSXとPlayStation 2のディスク読み取りエラーは、当時も非常にありふれていて致命的だった。
      しかし人々が気づいた頃には、すでにゲームを大量に所有した後だったので、そのまま新しいコンソールを買った。
  • ぎこちないSegaの構造の話が出たので、MattKCが最近セカンドチャンネルに投稿した32Xの動画もある。
    32Xを知らないなら、Genesisのカートリッジスロットに差し込んで、別の32ビットゲームラインアップを動かせるようにする奇妙なモジュールだった。
    本質的には2台のコンソールが一緒に動作する構造なので、映像出力を作るために2つのCPUが協力する、また別の状況だった。
    彼は実際にビデオケーブルをつないで試しているうちに、一方の機器の映像信号を切り離すと、もう一方でレンダリングされた出力だけが得られることを発見した。
    32X自体は3Dレンダリングを出力し、Genesisはメニュー、HUD、スプライトなどの2Dグラフィックスを供給していた。
    https://www.youtube.com/watch?v=rl9fjoolS2s