反論紹介
目次
プレステとの比較
反対にサターンの方が優れていたのは、メモリが高速だったこと。行列計算が32bit(16bit+16bit)固定少数で、プレステの16bit(14bit+2bit)より精度が抜群に良かったこと。
— kozo (@yukizokin) November 11, 2013
まず最初に訂正から。kozo さんから、14bit + 2bit は書き間違い、と訂正を頂いています。
プレステも固定小数点演算でしたが、4bit + 12bit でした。いずれにせよ、16bitの精度だった、という点が重要なので、些細な間違いです。
プレステのジオメトリエンジンは非常にややこしいので、説明するためにちょっと勉強してみました。付け焼刃なので間違いがあったらごめんなさい。
まず、ジオメトリエンジン(ＧＴＥ)自体は、32bitのプロセッサです。すべてのデータは 32bitで与えられます。
CPU である R3000 も 32bit プロセッサで、32bit づつのデータの受け渡しが得意です。なので、この点には特に問題はありません。
データは全て「レジスタ」に設定する形で与えられ、レジスタの数は 64本に限られていました。実は、十分な３Ｄ演算を行うには、この数が少なすぎる。
そのため、回転行列の値も、ポリゴンの頂点データも、16bit で表現して１つのレジスタに２つ詰め込まれていました。
この内部形式が、符号1bit、整数部分3bit、小数部分12bit 、合計で16bit、という形式でした。
サターン側の乗算器については過去に書いていますね。
SH1 を見たセガの担当者が、要望を出して改良してもらった部分です。
ＳＧＬでは、32bit の乗算器を使い、整数部分 16bit 、小数点以下の部分 16bit の固定小数点演算をしていました。
固定小数点と言うのは、事実上は整数演算です。
足し算、引き算、割り算は、なにも考えずにそのまま計算できます。
掛け算は、 32bit * 32bit で 64bit の結果を得た後で、中央の 32bit だけを取り出します。
（64bit の結果は、整数部分 32bit 、小数点部分 32bit になっています。これを、元の精度に戻すわけです）
サターンでは、計算精度がＧＴＥの 16bit の２倍、32bit あります。
最終的には 320x224 ドット程度の画面に出力されるので、そんなに精度高くなくても良い、というのも事実なのですが、３Ｄ演算は掛け算が繰り返されるため、途中で誤差が溜まりやすく、この程度の精度が無いと問題も出やすいのです。
これが、kozo さんが「サターンの方が精度が抜群に高かった」とする理由です。
以下余談。
ＳＧＬでは角度の表現が独特で、１周を 16bit 、65536段階に分割していました。
「桁あふれ」で 0 に戻るときに、角度も一周して 0 に戻るのです。
DEGREE (0～360度)でもRADIAN(0～2π)でも「範囲を超えた時」の処理はややこしくなってしまいますが、上手な割り切りだと思いました。
ＳＧＬでは、三角関数を高速に求めるために、関数の結果をデータとして持っていました。三角関数は３Ｄ演算になくてはならないものですが、この演算を行うプログラムは、SH2 の 4Kbyte しかないキャッシュに完全に収まる必要がありました。
このため、データを切り詰めるための工夫が見られます。
まず、tan のデータは不要です。tan(a) = sin(a)/cos(a) で求められます。
sin と cos の結果は、90度ずれているだけなので、同じデータを共有できます。
また、sin(-a) = -sin(a) なので、45度分のデータがあれば、90度分のデータを作り出せます。
これをうまく組み合わせれば、45度分…円の８分の１周のデータがあれば、すべての関数の結果を出すのに十分でした。
また、結果は基本的に小数点以下のみなので、固定小数点の 32bit データは不要で、16bit の小数部分だけで表現します。
そして、角度は 16bit 全てではなく、上位 12bit だけ、4096段階が使われました。この時、下位 4bit は切り捨てるのではなく、最終的に求めた結果に対し、-7～+8 の影響を与えます。
これで、持つべきデータは 4096 の 1/8 の 512角度。各データは 16bit なので、1Kbyte のデータがあれば、三角関数を計算できます。
三角関数データだけで 1Kbyte 、というのはギリギリの線で、これ以上少なければ演算精度が維持できず、これ以上多いとプログラム全体が 4Kbyte のキャッシュに収まらない、という容量になっています。
回転ＢＧ
回転BGも凄かったけどポリゴン性能との差がありすぎて使い道が無かった。回転BGの高精細さを生かそうとするとポリゴンが余計汚く見えるし、回転BGの巨大さを生かそうとすると平面的な地形デザインになり３D空間を活かしにくくなる。
— kozo (@yukizokin) November 11, 2013
回転BG用のメモリは高速だったので、ムービー展開用のリングバッファをそこに置いてメモリを100KB程度稼ぐとかしたような気がする。
— kozo (@yukizokin) November 11, 2013
ここら辺は、本来ポリゴンと組み合わせる意図はなかったのだろうと思っています。
バーチャファイターリミックスで使われて、それが普通の使い方みたいに思われてましたけど、本来２Ｄゲーム向けの機能なのではないのかな。
「使えない」の言葉を補佐しておきましょう。
回転BGは「画面全体」を覆う BG 画面でありながら、３Ｄ空間内で自由に回転・変形できる、というものでした。
これ、スーパーファミコンを超える、究極の２Ｄゲーム機として計画された時期の名残なんでしょうね。
スーパーファミコンは、画面回転機能があります。実は１軸回転（画面を２次元に捉え、回転する）しかできないのですが、ラスターごとに処理して縮小率を変えることで、画面奥方向に倒したように見せかけて、地面の表現ができました。
サターンの回転 BG 面は、最初から「ラスターごとの画面変形」機能があります。これを上手に設定すれば、３軸自由回転も可能でしたし、変形も出来ました。でも、スーファミの回転ＢＧ面のすごい奴、と言う位置づけを超えられないのです。
具体的に言えば、スーファミの「マリオカート」のように、凹凸のない地面は表現できます。でも、ポリゴンを駆使した、凹凸のある地面にはできません。
真っ平らなバーチャファイターのリングは表現できても、バンクやループのあるハードドライビン(1989年…サターンより５年も前に発売のポリゴンゲーム)のコースを作る役には立たないのです。
ただ、回転ＢＧ面の「自由変形」機能は（使うのは大変でしたが）面白い機能でした。
僕自身は２Ｄゲームで使おうとして、なにか面白い演出に使えないかいろいろ実験したことがあるのですが、そのゲーム自体がお蔵入りしました (^^;;
そして、回転ＢＧを使わない前提で、空いたメモリを別用途に使っていた…という話題。
VDP2 のメモリに関しては、どこにどの画面を割り振るかは任意に変更できたのですが、ＳＧＬではメモリの割り当てが決め打ちされていました。
あまり自由度が高いのも使いづらいので、決め打ちすることで簡単に使えるように…という配慮なのでしょうね。
でも、回転ＢＧは「使えない」存在だったし、ムービーシーンなどではなおさら不要。回転ＢＧ面を表示しない設定にして、高速バッファメモリとして使用した、ということですね。
これだって、メインメモリが開いていればメインメモリにバッファを入れるのかもしれませんが、「メインメモリが小さいからやむなく」VRAM をバッファとして使った、という苦労話。
先に書いた、「感覚的にはメインメモリが５分の１」という話の続きなのです。
そういえば、ムービー再生はプレステはハードウェアで持ってましたけど、サターンはソフト再生でしたね。この部分で大量にバッファを取られてしまう、というのも「メモリが窮屈」と感じる理由だったのかもしれません。
僕は ST-V で開発していて CD-ROM は使っていなかったので、ムービー向けのテクニックとかは知りませんでした。
ROM では CD-ROM 程の大容量は使えないから、ムービーなんて使いたくても使えないのよ (^^;