反論紹介

さて、サターン関連の話を書き始めて１年たってしまいましたが、書き始めの初期の頃（つまりは、１年前）に、早々に書いてあることの反論を頂いていました。

反論と言っても、間違いの指摘と言うよりは「別の角度から見た話」ですね。補完する情報。

間違いならすぐに修正するのですが、別角度からの話なので、僕の書きたいこと書いた後で紹介するつもりでした。

…結局書くのに１年かけてしまいましたが、今からでも紹介させてもらいます。

目次

セガ・サターン(別ページ)

サターンの３Ｄ性能(別ページ)

サターンのCPU(別ページ)

太陽系の惑星たち(別ページ)

細かな話題(別ページ)

もう一つのライブラリ(別ページ)

次世代ゲーム機戦争(別ページ)

はじめに

 注意・重要

テクスチャ表現

 8bitテクスチャ・シェーディング プレステとの比較

メモリ

ＳＧＬ

 プレステとの比較

回転ＢＧ

まとめ

はじめに

えー、いろいろなことがありまして、僕はこのサイトで嘘を書く、と宣言しています。

詳細はリンク先見てね。

この「嘘」は、意図せずに嘘が混入するであろう、という警告です。

わざわざ嘘を書きたいわけではありません。

僕もできるだけ事実を記録したいと思っています。

でも、個人の能力には限界があるから嘘が入ってしまいます。

先に書いた「いろいろなこと」の関連で、ゲーム業界にわずかな期間でも関係した人間として、何か記録を残せれば…と考えました。

今回書いている一連のサターンの話は、その行動のひとつ。

ただ、僕はゲーム業界の片隅で、サターンですらない互換機の「ST-V」のゲームを数本作っただけです。

「社外秘」だったはずのマニュアルの英語版もネットで見つかったりはしていますが、やはり情報は少ないです。

特に、実際にプログラムした使い勝手などは、僕の経験談のみで語っていた状況です。

そんな状況ですから、些細なことでも資料はうれしいです。

「反論」と書いていますが、同じようにサターンをプログラムしていた、なんて人からの思い出話は、何よりもありがたい資料でした。

さて、kozo さんからの反論です。Twitter でつぶやかれたものですが、本人の許可を得て転載いたします。

引用は投稿順ではありません。

kozo さんも思い出しながら書いているため、話題が分散していたためです。

技術に詳しいことを前提に書かれていますし、Twitter の少ない文字数では説明不足になりやすい点もあります。

そのため、合間に僕から説明を入れます。

注意・重要

kozo さんの好意でツイートを引用させていただいていますが、kozo さんは自分の記憶を適当に呟いただけで、このページに引用されることを想定したものではありませんでした。

そのため、記憶違いなども多々あるかと思います。記述に問題があった場合、kozo さんの責任ではなく、そのつぶやきを取り上げた僕の責任です。

文責は僕が負いますので、問い合わせや誤りの指摘などを kozo さんに送らないようにお願いします。

テクスチャ表現

本文中に書いていますが、プレステとの比較を行いながら、僕自身プレステに詳しくありません。

ST-V のゲームを開発している会社にいましたが、その会社では主にセガの業務用基板を使っていて、プレステ系のものは使わなかったので。

kozo さんの話は、実際に両方を知っている（kozo さん自身はサターンが専門だったそうですが、同じ会社でプレステの開発もやっていたそうです）ために、非常に具体的です。

まず最初に、ポリゴンの表示方法を再確認しておきます。

３Ｄの物体は、多数の「頂点」と、その頂点を結ぶ「辺」、そしてその辺で囲まれた「面」の組み合わせで表現されます。

３Ｄ座標を持つ頂点は、透視変換と呼ばれる数式で、２Ｄのテレビ画面に描き出されます。

この際、「面」を表現するのに、いくつかのテクニックがあります。

一つは、テクスチャマッピング。３Ｄの時点でも、頂点を結び合わせて面を表現するため、整った四角とは限りません。

それを２Ｄに変換すると、さらに歪みます。

でも、どんな形でも絵を変形させて貼り付けてやれば、面を表現できます。

これとは別に「シェーディング」と呼ばれる技術があります。

その「面」にどのように光が当たっているかを計算し、その光の量によって色を変えてやることで、立体感を演出します。

このシェーディング方法の一つが「グーローシェーディング」です。

面の向きなどで単純に光の当たり方を計算するのではなく、面の各頂点ごとに明るさを計算し、その間はグラデーションになっているのだろう、と見做します。

シェーディングについて、簡単に説明しておきます。

面単位で光を計算するのが「フラットシェーディング」。面のつなぎ目で急に明るさが変わるので、カクカクとした画像になります

これに対し、グーローシェーディングは上に書いた通り頂点ごとに明るさを計算しますが、この頂点は「隣接する面の平均」の方向を向いている、と考えます。

このため、面と面のつなぎ目で明るさが自然に変わり、つなぎ目を目立たなくしてくれます。

相変わらずポリゴンモデルは面単位で作られるため、カクカクしているのですが。

サターンは 16bit テクスチャじゃないとグーローシェーディングが使えなかった…。すっかり忘れていましたが、その通りです。

ポリゴンゲームには関与したのですが、そのゲームは（まさにメモリの制約で）「グーローは使わない」決定を最初からしていたのでこの制限のことを忘れていました。

サターンでは VDP1 と VDP2 に画像関係の LSI がわかれています。

VDP1 はポリゴンを描き、VDP2 は背景と重ね合わせ、最終的な画面出力を作り出します。

まず、セガサターンは RGB 値を基本的に 5bit づつ、15bit = ２バイトのデータとして持ちます。

（1677万色モードもありましたが、背景のみでスプライトには使えません）

ただ、そのままでは１ドットごとに２バイトが必要となってしまい、メモリが大量に必要です。

そこで、この方法で使える色の中から、任意に 16色、または 256色を選んで「対応表」（パレット）をつくり、パレット内の番号を使って絵を描くことができました。

この方法を使うと、１ドットごとに 4～8bit となるため、メモリの節約になります。

それだけではありません。この方法では「任意に選んだ 16色」などで絵を描きますが、この 16色を１組としたパレットを、複数持てるのです。

描画時に「どの組み合わせで描くか」を指定することができました。

これにより「色違いの敵」などは、同じ絵のデータで表示を変えられます。

１ドットが２バイトだったのが 4bit になったから 1/4 になった、というだけでなく、色違いの敵などを同じデータにまとめられるので、もっと減るのです。

さて、「メモリの節約になる」だけならいいのですが、問題も出ます。

VDP1 は、指定されたテクスチャをただ機械的に VDP2 に送ることしかできません。送られたデータがどんな色か、パレットを調べ、実際の表示を行うのは VDP2 です。

ところが、ポリゴン表示の際に使われる「グーローシェーディング」とは、テクスチャに対して、ドットごとに色演算を行う処理なのです。

テクスチャ描画の際に処理するため、VDP1 が処理を行わなくてはなりません。

ここに問題が生じます。

VDP1 は色を知ることができないが、色演算をしなくてはならない。

ただ、VDP1 が色を知ることができる方法が、たった一つだけあります。

「対応表を使わず、色を直接指定する」方法です。

つまり、１ドットについて２バイトを使い、16色テクスチャの４倍以上のメモリを使用するのです。

これなら VDP1 が色を知ることができるため、グーローシェーディングの処理が行えます。

これが、kozo さんの指摘した「16bit テクスチャでないとグーローシェーディングが使えない」問題です。

パレットを使用する 4～8bit テクスチャと、RGB直接指定の 16bit テクスチャの混在も可能でした。

ただし、この場合パレット指定によるスプライトの表示に、少し制限が出ます。

最終的な表示を行う VDP2 は、スプライト画面を「１ドット２バイト」のデータとして処理します。

全てがスプライトなら、この ２バイト = 16bit を全て、スプライトの各種パラメーターとして使えます。

しかし、RGB と混在する場合は、「RGB データ」なのか、「パレットスプライトデータ」なのか、見分けるために 1bit が必要でした。

RGB データはもともと 5bit づつの 15bit なので、1bit 空いています。パレットスプライトは、何かのデータを削って、1bit の余裕を開ける必要がありました。

削られるものは、重ね合わせの優先順位や半透明度、色数など。詳しくは後でもう一度書きます。

いずれにせよ、「混在しないとテクスチャメモリが大量に必要で、混在すると使えるスプライト機能が減る」のです。どうにも使いづらい仕様でした。

次ページ: 8bitテクスチャ・シェーディング