1 ポイント 投稿者 GN⁺ 2024-07-30 | 1件のコメント | WhatsAppで共有
  • SNESのビデオは、1990年代初頭のCRTテレビとNTSC信号の制約の中で、256x224画面、60.098Hzのフレームレート、ブランキング期間に合わせて設計されていた
  • CRTはピクセル格子ではなく、電子銃とRGB信号、HSYNC/VSYNCで走査線を描画し、プログレッシブとインターレースも同期信号の位置の違いで分かれる
  • 専用のビデオオシレーターを搭載できなかったSNESは、21.47727MHzのマスタークロックを分周して5.3693175MHzのドットクロックを作り、262ライン・341ドットの組み合わせで、NTSC標準の59.94Hzとは異なる60.098Hzに到達した
  • 基本モードは、262ライン中224ライン表示と38ラインのVBLANK、341ドット中256ドット表示と85ドットのHBLANKで構成され、PPUがスプライトのラインバッファを処理する時間を確保していた
  • PAL版SNESは50Hz・312.5ライン環境に合わせて別のオシレーターと240ラインのオーバースキャンモードを提供したが、ほとんどのゲームは224ライン基準だったため、黒帯と17%遅い動作が一般的だった

CRTテレビが設計を制約した点

  • SNESが映像を出力する主な対象は標準的なCRTテレビで、当時のテレビはアンテナでNTSCアナログ放送を受信するか、AUX入力で外部映像を受け取っていた
  • 一般的なテレビの補助入力は、黄色のコンポジットビデオ端子と、白・赤のステレオ音声端子で構成されていた
  • CRTは、毎秒約15,000本の線を描ける15kHz級の線描画装置と見なせる

CRTはピクセルではなく走査線と信号で動作する

  • CRT内部には3つの電子銃があり、電子は垂直・水平の磁石によって上下左右に曲げられる
  • 電子自体には色がなく、マスクが各電子銃の電子を正しい色の蛍光体ストリップに当てる
  • CRTにはピクセルがなく、スロットもピクセルではない
    • 高解像度テレビではスロットがより小さく、同じ色信号を水平方向により忠実に表現できる
  • CRTは5つの信号を4本の線で受け取る
    • Red、Green、Blue信号はそれぞれ電子銃に直接接続される
    • 3本のRGB線に信号がなければ電子は発射されず、黒が表示される
    • 白い線はComposite Sync(CSYNC) としてHSYNCとVSYNCをまとめて伝送する
  • CRTはVSYNCを生成せず、外部システムが送る同期信号を受け取って電子銃の位置を合わせる

プログレッシブとインターレースの違い

  • CRTは1本の線を左から右へ描き、HSYNCを受け取ると画面左端のX=0へ戻る
  • VSYNCを受け取ると画面上端のY=0へ戻る
  • 電子銃は右へ移動する間、下向きに傾いた経路をたどり、HSYNC後の次の線は前の線の下に描かれる
  • VSYNCが最後のHSYNCと同じタイミングで発生すると、同じ位置にフィールドが描かれるプログレッシブスキャンになる
  • VSYNCが2つのHSYNCの間で発生すると、次のフィールドの線が前のフィールドの間に入るインターレースになる
    • インターレースは垂直解像度を2倍にするが、各線の更新率は半分に落ちる
  • NTSCは約30Hzで2つのフィールドを出力するため、CRTはインターレース用の線間隔を確保しており、プログレッシブで描くと黒い走査線の隙間が見える

NTSC仕様と単純な設計案の限界

  • SNESの設計は、NTSCテレビが処理できる値に近い必要があった
    • アスペクト比: 4:3
    • フィールドあたりのライン数: 262.5
    • 1ラインあたりのドット数: 341.25
    • フィールド周波数: 59.94Hz
  • 白黒NTSCはもともと60Hzだったが、カラーNTSCは後方互換性を保ちながら色を追加する過程で、アーティファクトを避けるため周波数を0.1%下げた
  • 単純には、262ラインのプログレッシブ、350ドット、59.94Hzを選び、5,496,498Hzのドットクロックを要求することもできる
  • しかしこの設計は実際のSNESには合わなかった
    • コスト制約のためビデオシステム専用のオシレーターを置けず、サブシステムはマスターオシレーターを分周して使う必要があった
    • CRTは画面復帰中にも電子銃が発射され続ける可能性があり、オーバースキャンとブランキング処理が必要だった

ブランキングと垂直解像度の選択

  • 電子銃の位置が水平または垂直にリセットされるとき、電子を撃ち続けると見えるアーティファクトが発生する
  • テレビは画面より少し大きな絵を表示するオーバースキャンを行い、その程度はテレビごとに異なる
  • VSYNCとHSYNCの後は電子銃の位置がしばらく揺れるため、安定した直線を得るまで電子の発射を止める時間が必要になる
    • VSYNC後に電子発射を停止する区間がVBLANK
    • HSYNC後に電子発射を停止する区間がHBLANK
  • 当時の競合システムもブランキングを使っていた
    • Capcom CPS-1: 262ライン、VBLANK 38ライン、表示224ライン、59.6294fps
    • Sega Genesis: 262ライン、VBLANK 38ライン、表示224ライン、59.9227fps
    • Neo-Geo AES: 264ライン、VBLANK 40ライン、表示224ライン、59.18fps
  • SNESは262ラインを224表示ライン + 38ブランクラインに分けた
    • 224は16で割り切れるため、16x16タイルベースのグラフィックスパイプラインと相性がよい

水平解像度と60.098Hz

  • SNESは21.47727MHzのマスタークロックを4で割り、5.3693175MHzのドットクロックを使用する
  • フレームレート、ライン数、1ラインあたりのドット数、ドットクロックは相互に結び付いている
  • 目標フレームレート59.94Hzと262ラインを入れると1ラインあたり約342ドットになるが、コンポジット出力のキャリアアーティファクトのため、Nintendoのエンジニアは341ドットを使う必要があった
  • この組み合わせでSNESのフレームレートは 5.3693175MHz / (341 * 262) = 60.098Hz となる
  • 60.098HzはNTSCの59.94Hzとは異なるが、CRTの許容範囲内で動作する

256x224が基本画面になった理由

  • 1ライン341ドットすべてを表示領域として使うことはできず、揺れ・アーティファクト・テレビのオーバースキャンを隠すためのHBLANKが必要になる
  • 224ラインで4:3に近い表示幅は 224 * 4/3 = 298ドットである
  • タイルマップパイプラインは16x16タイルを使うため、可能な値は304、288、272、256、240などになる
    • 304ドットは画面の歪みがほぼない値に近い
  • PPUがHBLANK中にスプライトのラインバッファを埋めなければならないという制約もあった
    • 304ドット表示を選ぶとHBLANKは37ドット、約7µsにとどまる
    • 最大128個のスプライトデータを取得するには、より長い時間が必要だった可能性がある
  • 最終的な選択は256表示ドット + 85 HBLANKドットだった
    • PPUはHBLANK中に約16µsを確保する
    • 表示領域のアスペクト比は4:3ではなく8:7で、CRT表示時にわずかな歪みが生じる

高解像度モードでの妥協

  • 基本的なSNESビデオ構成は、オーバースキャン解像度341x262、表示解像度256x224、フレームレート60.098Hzである
  • ゲームの99%はこの構成を使ったが、SNESには垂直または水平解像度を2倍にする高解像度モードもある
  • 垂直解像度448ラインは、VSYNCを最後のHSYNCの半ライン後の地点で出力してインターレースフレームを作ればよい
    • この場合、1ラインは60.098/2 = 30.049Hzで更新される
    • ちらつきが発生して見栄えはよくないが、垂直解像度は上がる
  • 水平解像度の2倍化は、必要なドットクロックがないためより難しい
    • SNESは2番目のフィールドを水平方向に少し移動させ、点が前のフィールドの点の間に来るようにする
    • 結果として、半分のフレームレートと大きな色にじみが発生する
  • fullsnes.txtは、複数タイトルでの高解像度使用例をまとめている
    • Donkey Kong Country 1のNintendoロゴ: 512x224, BgMode5
    • Seiken Densetsu 2の設定画面: 512x224, BgMode5
    • RPM Racing: イントロとゲーム内で512x448, BgMode5+Interlace
    • Ranma 1/2の例は実際には256x224だが、インターレースが偶然有効になっており、不要なちらつきが発生する

PAL、SECAM、欧州版SNESの問題

  • 欧州のテレビはNTSCではなくPALを使い、フランスではSECAMも使われた
  • PAL環境は正確に50Hzとフィールドあたり312.5ラインを想定する
  • PAL版SNESはNTSCの21.4772700MHzの代わりに17.7344750MHzオシレーターを搭載する
    • S-CLKチップが6/5処理を行い、さらに/4で分周して5.32034250MHzのドットクロックを作る
  • 224ラインのグラフィックスだけを使うと、表示領域の上下に大きな黒帯が生じる
  • これを減らすため、表示ラインを240に増やすオーバースキャンモードがあった
    • 追加の16ラインはタイル1つ分の高さに相当する
    • 実際にはほとんどのタイトルが224ラインに合わせて制作されており、このモードはほぼ使われなかった
    • 使用したタイトルは合計12本のみ
  • Super Mario WorldはPALで垂直方向の視野範囲を広げる形で対応した
  • NTSCとPALはいずれも4:3のアスペクト比を使うため、PAL画像はNTSCより垂直方向に少し圧縮される
  • 多くのゲームコードは、VSYNCが60.098Hzではなく50.00697891Hzで発生する点を反映しておらず、その結果ゲームは意図より17%遅く動作した

出力信号とAVコネクタ

  • ここまで見てきたRGBと同期信号はCRTを直接駆動する純粋な信号だが、実際のテレビの多くはCRTに直接信号を入力できなかった
  • 多くのテレビは背面に黄色のコンポジット入力しか持たず、一部の高級モデルはS-Video入力を提供していた
  • SNESはCRT用の信号をコンポジットとS-Videoの両方に変換する
  • AVコネクタは信号を捨てず、複数の出力方式を提供する
    • Red, Green, Blue
    • C-Sync
    • LuminanceとChrominanceベースのS-Video
    • Composite Video
    • +5V DC
    • Ground
    • Left Audio, Right Audio
  • 欧州のテレビ、特にフランスのテレビはSCARTコネクタを備えている場合が多く、この方式によりCRTへより直接的に信号を入れるケーブルの制作が可能になった
  • その結果、欧州のユーザーは17%遅く黒帯のあるゲームを、高い映像忠実度で楽しむことができた

1件のコメント

 
GN⁺ 2024-07-30
Hacker News のコメント
  • 224はランダムに選ばれた数字ではない可能性が高い。16で割り切れるため(224/16=14)、グラフィックレンダリングパイプラインのタイルマップとうまく合う
    子どもの頃、ゲームプログラミングを学ぼうとしてあれこれ触っていたが、ずっと後になってようやく理解し、そのとき大いに納得した。CGA/EGA/VGAでは320x200モードが一般的で、NESとSNESは256x224だったが、これは実質的にはテレビ側の制約に近かった
    一方、アーケード版Pac-Manは288x224だったため、PCのPac-Manクローンは決して「正しく」見えず、Namcoが作ったNES版Pac-Manでさえ合っていなかった。マップタイルが小さくなってキャラクターが巨大に見えたり、Game Boy/Tengen版のようにスクロールするワールドになったり、歪みや非オリジナルのマップといった妥協が入ったりして、家で「アーケード」ゲームを遊ぼうとすると妙で窮屈に感じた
    ハードウェアの構造とスプライトの動作方式を学ぶと、結局ほかに選択肢はなかったのだという結論に至り、大きな気づきがあった。PCのその解像度ではピクセルが正方形ではないという事実まで含めると、さらに複雑になる
    それ以来、Pac-Manの移植版やクローンを見るたびに、ワールドサイズ、タイルサイズ、スプライトサイズをすぐ確認するようになった

    • NESは実際には256x240で、NTSCフィールドの240ラインすべてを使っていたが、多くのテレビが上下の一部を切り落としていたため、ほとんどのテレビで安全な「利用可能」領域は256x224だった
      ただし、このオーバースキャンはテレビごとに異なり、現代のテレビやエミュレーターでは通常240ラインすべてを表示する
      SNESの縦解像度は、記事にあるように224ラインまたは240ラインに設定できた。ほとんどのゲームは224ラインを使っていたが、垂直ブランキング時間が長くなり、PPUへグラフィックを転送する時間が増えるためである
    • 昔から、いくつかの移植版がアーケード版より縦に伸びて見えると感じていたが、なぜなのかはまったく分からなかった。Atari 8-bitコンピューター向けの旧版やMs. Pac-Man、Super Pac-Manなどの複数のバージョンも同じだった
  • Rodrigo CopettiによるSNESの構造解説も併せて読む価値がある: https://www.copetti.org/writings/consoles/super-nintendo/

  • 59.94Hzが奇妙な数字なのは確かだが、知る限り30Hzの電力網は存在しない。NTSCが設計された北米といくつかの地域では60Hzの電力網を使っている
    https://en.wikipedia.org/wiki/Mains_electricity_by_country

    • もともと白黒テレビでは毎秒60フィールド、つまり毎秒30枚のインターレースフレームだった
      白黒テレビで生成される最も高い周波数は水平走査周波数で、これはフレームレートの倍数だった。3.579545MHzの搬送波を使うNTSCカラー信号が追加されたことで、テレビ内部の最高周波数ははるかに高くなり、ハードウェアを単純に保つため、低い周波数は引き続きその最高周波数、すなわちカラー搬送波の約数に合わせられた。その結果、フレームレートは毎秒59.94フィールドになった
  • PAL地域でゲームが50.00697891HzのVSYNCに合わせて修正されておらず、60.098Hz基準より17%遅く動いていたという部分がとても実感として伝わる
    Super Nintendoだけの話ではないが、Mega Drive(Genesis)でSonic the Hedgehogを初めて見たりプレイしたりしたときのことを思い出す。Master System版よりも鈍く遅く感じられて、あまり印象に残らなかったのだが、YouTubeが出てきてからようやくNTSCとPALの速度差がものすごいものだと分かった。ゲーム速度だけでなく、音楽もPALではひどく聞こえる
    16ビット時代にもPALと「黒い箱」の必要性は知っていたが、差がそこまでだとは思っていなかった。当時のコンソール雑誌は、たいていのゲームでは差は小さいと言っていたように思うし、例外的にSNES版DooMはNTSC版の画面のほうが大きかった
    NES版Punch-Outは子どものころ得意で、Mr. DreamまたはMike Tysonを1ラウンドで倒せたのだが、今思うとPAL版をやっていたということだ。アメリカの大会に出ていたら1ラウンドで叩きのめされていただろうし、誰かが自分を罠にはめたのだと確信していたはずだ

    • Super Metroidは、開発陣がPALコンソールでも正しい速度で遊べるように修正したゲーム。ただしそうした調整も、特にスピードランでは物理定数やアニメーションのタイミングのわずかな違いによって、実際のプレイ上の差を生む
      例えば低いフレームレートではSamusと発射体が1フレームあたりにより多くのピクセルを移動するため、物体をすり抜けやすくなり、このゲートグリッチはPALでのみ可能になる: https://www.youtube.com/watch?v=RvyIwtO_qgM
      Samusの物理定数とアニメーションタイミングは新しいフレームレートに合わせて調整されたが、敵・カットシーン・その他の環境要素は調整されていない。そのためPALではSamusはNTSCと同じ速度で動くが、それ以外の世界はより遅く動く。このためBombsを拾って、扉がロックされる直前に部屋を出ることでミニボスをスキップできる: https://www.youtube.com/watch?v=R3t8TIIj7IM
      NTSC版で同じスキップを行うには複雑な準備と、フレーム単位の入力を何十回も連続で行う必要があり、これまで成功したのはたった1人だけだ: https://www.youtube.com/watch?v=jcKUMk5g8Wk
      NTSC(左)とPAL(右)の最短ツールアシスト・スピードランの比較もある: https://www.youtube.com/watch?v=KD_-thqcB5s 2つのランはほぼ最後まで同じルートを使い、NTSC版はほぼすべての部屋でより速いが、任意コード実行の準備がまったく異なるため、最終的にはPALのほうが先に終わる。NTSCのランでは、扉を作動させずに通過して境界外へ出てメモリ破壊を起こすために、非常に遅いポーズ/解除シーケンスを行う必要がある。一方PAL版では、ゲームのアニメーションシステムの競合状態を利用して、完全に画面内で任意コード実行を達成できる。スパイクのノックバックタイマーとSamusの着地アニメーションの間の競合で、SamusのタイミングだけがPAL向けに修正され、スパイクはそうではないため、PALではこの文脈でのみ悪用可能なタイミングが生じる
    • オーストラリアでは『Hyper』のような雑誌のおかげでタイミングの違いは知っていたが、できることは何もなかった。むしろ知らずに幸せに暮らせたかもしれないのに
      Dreamcastが出て、初めてテレビが対応してさえいれば50Hzと60Hzを切り替えられるゲームが登場した。また、この違いをきちんと反映していないゲームでは50Hzに戻して簡単にすることもでき、Crazy Taxiは50Hzだとはるかに簡単だったと記憶している
    • エミュレータでSNESゲームを遊ぶたびにタイミングがずれる理由は、これで説明できるのかもしれない。子どものころはPAL版で育ち、今までは現代のテレビの遅延のせいだとばかり思っていた
    • アメリカで育ったが、後になってPALと米国版の間の速度差を初めて聞いたときは衝撃を受けた
      そんなに違うゲームがそのまま売られていたのは奇妙に感じるが、なぜそういう選択になったのかは完全に理解できる。子どものころはMarioはどこでもMarioで、SonicもどこでもSonicだと当然のように思っていた
      こうした違いがなくなったのは3Dコンソールの時期だったのか気になる。そのころからレンダリングとゲームロジックは、ほとんどの場合もはや完全には結び付いていなかったからだ
  • 原文にタイプミスがあるようだ。アスペクト比を8:6としているが、それは4:3と同じで、計算上は8:7が正しい

    • その通り。内部アスペクト比は8:7で、Snes9xのようなエミュレータもデフォルト値はこちらだ。CRTでは動作の仕組み上、完全な正方形ピクセルを長方形に押しつぶすため、結果として4:3に近く表示されるのだと理解している
  • 256x224、つまり8:7の出力解像度が約4:3、正確には64:49の画像に引き伸ばされる部分が抜けているように思う
    SNESのドットクロックは約5.37MHzで、ATSC標準が定義する正方形ピクセルの速度である約6.13MHzより遅い。正確に8/7だけ遅いため、ピクセルは横方向に8/7伸び、8:7の解像度は(8/7)(8/7)=64/49に引き伸ばされ、64:48=4:3に近くなる
    「4:3に近いアスペクト比にするには224
    (4/3)=298個の可視ドットが必要だ」という計算は、上の要素を考慮すると係数が(4/3)/(8/7)=7/6になる。すると224*(7/6)=261.33...個の可視ドットが必要になり、実際に選ばれた256にずっと近くなる

  • 私はRF出力にスイッチボックスをつないで、SNESとテレビアンテナを交互に選んで使っていた

    • それ以上に画質を悪くしてノイズを加える方法は、RFスイッチボックスとテレビの間に2線式のUHFネジ端子アダプタを挟むことくらいだった。もちろん子どものころ持っていた1970年代風のPongもどきコンソールでは、まさにそうやって使っていた。本物のAtariを買う余裕はなかった
      後にビデオエンジニアになってからは笑えるようになったが、当時の幼い自分がその画質がどれほどひどいものか知らなかったのは幸いだった
  • 8:7のアートワークのアスペクト比は、ROCKMANX3 / Mega Man X3 のような SFC/SNES の他プラットフォーム移植版でも見られる
    PSX/Saturn/PC版は元のアートを引き伸ばさずに維持した代わりに、8:7を4:3に合わせるため、ステージに合わせた上下の余白を追加している。元のバージョンに慣れているとプレイ時にかなり気になり、Saturn版のスクリーンショットを見ると、すべてが少し細すぎるように見えるのが分かる: https://segaretro.org/Mega_Man_X3

  • Fabienがこういう記事を書くのにどれくらい時間がかかるのか気になる。細部が本当に多く、整理もきれい

    • だいたい日曜日を丸一日、午前9時から夜9時までかかった
  • SNESの解像度のうち、どれだけがコンソールのハードウェアに固定されていて、どれだけがカートリッジ側で駆動できる領域なのか気になる
    例えば独自の補助プロセッサがあってスプライトを読み込む必要がなく、オンボードクロックもあるカートリッジなら、理論上は1ラインに横256ピクセルより多く出力できたのだろうか?

    • すべてPPUに固定されていると見ている
      補助プロセッサがあれば、自前でフレームをレンダリングして、次のラインのタイルが読み込まれるメモリ位置に置くことはできる。SuperFXがだいたいそんなことをしていたと思う
      しかし結局、実際にピクセルを描き、色数などを処理するのはPPUなので、最終的にはPPUの制約に縛られる