僕は、NAOMI が発売して少し経ったところでセガを辞めています。
なので、NAOMI 向けのゲームはあまり知りません。
しかし、NAOMI 発売以前から、いくつかの初期タイトルを開発していたのは知っています。
今回はそうしたゲームの一つの話。
実際にゲームが発売されたのは、1999年の夏で、NAOMI 用ではなくなっていました。
でも、20年前…1998年の秋ごろに、NAOMI 用として開発を始めたのです。
ドリームキャスト / NAOMI で採用されたグラフィックチップ、PowerVR2 は、独特のレンダリングアルゴリズムにより非常に高速…
という触れ込みでした。
レンダリングというのは、画面を描画する処理のことね。
三角形、または四角形で表現されるポリゴンの各頂点の３Ｄ座標と、そこに描かれる「テクスチャ画像」を渡されて、実際に２Ｄの画面に反映する処理。
サターンでは、ソフトウェアでポリゴンを奥行き方向に並べ、奥から順に描いていました。
同じ位置にポリゴンがあると、手前のもので上書きされます。これにより、「奥のものは見えない」という３Ｄ画像を作り上げるのです。
奥行きをＺ軸と表現するため、奥行き順に並べ（ソート）て描画するこの方法は、Ｚソート法と呼ばれます。
しかし、いちいちＺ方向に並べてから描画、というのはプログラムの手間が大きいです。
現在主流の方法では、順不同にポリゴンを描画していく処理になっています。
この時、描画する画面の「色」だけでなく、そこに描画されている色の「Ｚ座標」も記録しておきます。
新たなポリゴンを描画する際、現在のＺ座標よりも手前の時だけ描画を行い、奥の場合は何もしないで捨てます。
Ｚ座標を溜めて（バッファ）おくことから、Ｚバッファ法と呼ばれます。
PowerVR2 では、事前に画面を細かな「ブロック」に区切ります。
そして、やはり順不同にポリゴンデータを与えるのですが、各ブロックごとに、そのポリゴンがブロックに関係するかどうかを見極めます。
ブロックに関係するなら、以前に関係すると判別したポリゴンよりも手前かどうかを判別し、常に一番手前のものだけを覚えておきます。
最後に、一番手前に来たポリゴンだけを描画して終わり。
描画処理というのは結構時間がかかります。
テクスチャを読みだして、ドットごとに座標変換して、変換先のメモリに書き込まないといけないから。
しかし、描くべきポリゴンを最初に見極め、最後に描画を行えば、せっかく描いたものを上書きする、という無駄を生じません。
このため、PowerVR2 は当時のポリゴン描画プロセッサとしては非常に速度が速く、Ｚバッファが不要なのでメモリも少なくて済んだのです。
しかし、これは「理論上は」という話。
PowerVR2 は、セガの要望をもとに PowerVR を改良した LSI でした。
PowerVR では確かに高速のポリゴン描画ができたのですが、致命的な欠点があり、ゲームには使えなかったのです。
それは「ポリゴン単位で」一番手前以外は描かない、というところ。
ゲーム機では、３Ｄ以外の表示物も存在します。
たとえば、得点表示。単に数字を描きたいです。
そこで、周囲が透明になる数字の画像を作り、ポリゴンのテクスチャとして、パースがつかないように画面に配置したとしましょう。
常に表示したいので、「一番手前」に表示したとします。
ただこれだけで、描画が破綻します。
「一番手前のポリゴン」しか描きませんから、たとえテクスチャの周囲が透明でも、その奥は一切描画されないのです。
さすがにこれではゲームに使えない、というわけで、透明を含むテクスチャが使えるように改良されました。
ただ、透明かどうかはテクスチャを参照するまでわかりません。
「ポリゴン単位で処理し、最後にテクスチャを参照して描く」というPowerVR の基本アルゴリズムと相性が悪く、多少処理速度が落ちます。
でも、透明なら、まだ「少し遅い」と言える程度なんだ。
セガからの要望はもう一つあって、半透明が使えるようになりました。
こちらは奥から順に処理しないと正しい半透明にならないため、一番手前だけの処理、というわけにいきません。
ポリゴン１枚にかかる処理時間が、半透明が入ると30倍に伸びました。
これはもう、半透明は使ってはならない、使うとしても多用してはならない、ということですね。
そういうマシンスペックなのです。
ところが、です。
こんな細かな話が分かってきたのは、実際に動く試作機が出来上がってからの話。
まだ実機ができる前から、NAOMI 向けのゲームの企画は始まっていました。
ST-V とは違い、すごいことができる、というのを見せつけるようなゲームを作らないといけない。
たくさんのポリゴンが出せるそうだし、半透明も綺麗だそうなので、それを見せつけるようなビジュアルのゲームを作ろう。
というわけで、水・炎・空気を表現するような、すごいビジュアルのゲームが企画されました。
炎と煙の中を進み、放水銃で鎮火させる消防士の物語。
でも、実機で作ってみると、全然想定していたような美麗な画像が作れないわけですよ。
企画者の頭の中では、映画と見間違うばかりの迫力のある炎と、飛沫を散らして放水する様子が思い浮かんでいたらしいのですが…
先に書いたように、これらは全部半透明で描かないといけないですし、半透明を使うと性能が 1/30 に落ち込んでしまう。
結果として表示できるポリゴン数が減り、ST-V とそれほど変わらないような、カクカクのポリゴンになってしまう。
それなりの規模のプロジェクトでしたが、同期が一人アサインされ、水の表現を任されていました。
でも、どうやっても美しい表現になんてならないのね。
放水する水を柱状のポリゴンで表現すると、どうやっても柱で殴っているように見えてしまう。
じゃぁ、丸い板の連続で表現すると、System32 のゲームのような、古臭い表現になってしまう。
何をやっても企画者からダメだしされます。
NAOMI の性能ではこれ以上のことはできないし、どうしようもないよ…と僕に愚痴っていました。
最終的に企画者は彼の能力が低いのだとみなしました。
部長に掛け合って別のプログラマーがアサインされ、彼は担当を外されます。
でも、後任の人もやはり同じ表現しかできないのです。当然です。それが機械の限界なのだから。
同期だからよく知っていますが、彼はプログラマーとして決して腕は悪くありませんでした。むしろできるほう。
でも、高専卒で、大学は出ていないのです。この学歴で、腕がないと見られた。
彼としてはこの処遇に不満だったようで、この１年くらい後に会社を辞めています。
このゲーム、のちに対象ボードを HIKARU に変更して「消防士」として完成していますね。
僕が会社にいたときにはまだ HIKARU 基板はなかったため、詳細は知りません。
ネットの情報によれば、半透明処理時の描画能力が NAOMI の４倍あったそうで、ここでやっと「当初思い描いていた」性能が出たのかもしれません。
それでも、動画を見た限りだと、最初の予定と水の見せ方がずいぶん変わっています。
同期が任され、苦労していた段階では、必ず画面下左右から、弓なりに放水する様子を描くことになっていました。
そのほうが水がよく見えるから。
でも、「水がよく見える」ということは、半透明を使う部分が増えるということです。
ゲーム動画を見る限りでは、画面上を放水銃自身が動くことになっていて、放水自体はほとんど見えないように描かれています。
結局、ボード性能をさらに高いものに変えても、最初に考えていたような表現方法では作るのが難しかったのでしょう。
水と炎と空気の表現って、今でも難易度の高いものなので、当時の技術でリアルタイムに作り出すのは無謀だったのだと思います。
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |