mieki256's diary

3D座標計算後の頂点座標だけ得られたらOKという話なら、容量・転送速度も楽になりそうだなと。

表示に使うだけだから、座標値を実数ではなく整数で持っても充分だし。画面モードが 256x224ドットだったと仮定すれば、x座標で1バイト、y座標で1バイト、つまり頂点1つにつき2バイトあれば足りるので、三角形ポリゴンを1枚描画するために必要なバイト数は、2バイト x 3 = 6バイトで済みますぜ、ということになる。

たったの6バイトで、画面の半分を塗りつぶすことだってできるぞ！ 凄い！ 圧倒的じゃないか！

で。ホントかウソかは知らないけれど、シルフィードは5000ポリゴンを何かの目安にしていた、という話も見かけて。

となると、5000ポリゴンを描画するためには、6バイト x 5000ポリゴン = 30000バイトほどあれば…。

アレ？ CD-ROMから読み込めるバイト数は、1フレームあたり 10240バイト前後のはずだけど。頂点座標だけでも3倍のバイト数だぞ？ しかも、各ポリゴンに色情報も持たせなきゃいけないから、必要なバイト数はもっと増えていくはずで。なのに頂点情報だけでもCD-ROMからの転送量をオーバーしてるよ。どうなってんの？

上記のデータの持ち方は単純過ぎるのかな…。一般的に、ポリゴン群のデータを持つ際は、各頂点に番号をつけて、ポリゴンは自身が必要とする頂点の番号を持ってるのがフツー。頂点を共有してるポリゴンが多ければ多いほど、頂点座標データは少なくなるし、そのことで各頂点の座標計算量も少なくなる。いいことづくめ。なので、シルフィードもそうしている可能性がありそう。まあ、座標計算量はこの際全然関係ないけど、転送量が減るなら、やらない手はないよなと。

だけど…。それで、1/3までバイト数が減るのかな？ 別途、頂点番号を持つということは、その分のバイト数が増えるわけです。それを考えると、さすがに1/3にはならないのでは。一体どうなってるんだ…？

まあ、最大では5000ポリゴン、って話かもしれないか…。転送量がオーバーしたらフレームレートを落とすという選択肢もありそうだし…。

それとも、圧縮データを読み込んで展開してるのかな。でも、そんな余裕あるのかな…。当時、ROMタイトルでもLZなんとかで圧縮してデータ持ってて、展開に数フレームかかった記憶があるんだけど…。圧縮アルゴリズムによっては、もっと速くできたのかな…。

転送量とはまた別に。本当に5000ポリゴンも、MC68000で描画できるんですか？ という疑問も。あのCPU(MPU)は当時ですら、「使い勝手はいいが、遅い」と言われてたわけで…。

頂点情報だけストリーミングして、というやり方だと、ポリゴンの隠面消去はZソート法で ―― 奥のポリゴンから手前のポリゴンへと上書き描画していくことで見えない部分を隠すことになるだろうけど。当時のCPUでポリゴン1枚描くのって、結構ヘビーなことじゃなかったかなと。何せ、整数演算だけで実数演算に近い結果を出す _DDA 等を駆使してた時代だし。

非力なCPUで、それなりの処理時間をかけてせっかく描いたポリゴンの上に、また別のポリゴンを描画しちゃう、しかもそんなことを 5000回繰り返す…。そんな余裕は無さそうだけど。

このあたり、X68Kを使ってた人なら、体感的に分かるのかもしれないですな…。「X68Kで5000ポリゴンを塗りつぶし？ それで15FPSをキープ？ 無理無理。寝言は寝て言え」だったのか。「余裕っしょ。そのくらいは楽勝。MC68000をナメンナヨ」だったのか。自分はX68Kユーザじゃないので、さっぱり分からんのですけど。

さておき。そこで思い出したのが、MEGA-CDで追加された回転拡大縮小機能。もしかしてソイツを使うのかなと。

ここから先は、どこかで誰かから聞いた話の受け売りのような気もしますけど。それとも当時の雑誌に書いてあったことなのかな…。でもまあ、一応書いとこうかな…。

これは想像ですけど、MEGA-CDの回転拡大縮小機能ってのは、画像変形後のキャラパターンを本体RAMに書き出してくれるハードウェアだったんじゃないかなと。 *1

「変形画像を作るところまでは、ハードウェアでやってやるよ。本体RAMにぶち込んでやるぜ」
「だけど、それを画面に出すためには、本体RAMからVRAMに転送しなきゃいかんぞ」
「VRAMへの転送は、ソフトウェア(各ゲームのプログラム)でやってくれよな。俺はそこまで面倒見ないから」

てな仕組みだったのかなと。

でも、MEGA-CDの表示部分 ―― TV出力はメガドラが担当してたから、VRAM転送回りもメガドラそのままで相変わらず遅くて。そのVRAM転送速度に合わせていくと、フレームレートは低くなっちゃう。だからMEGA-CDは、スーファミのように、回転拡大縮小画面を60FPSでグリグリキビキビ滑らかに動かせない。

MEGA-CD起動直後に、ロゴ画像が回転拡大縮小変形その他色々を「どやぁ」って感じでやってますけど。あの時点で既に、フレームレートが低く見えた記憶もあって。ガクガクというか、若干紙芝居状態というか。アレってたぶん、メガドラ側のVRAM転送速度が足を引っ張ってたんじゃないかなあ。まあ、そもそもあの起動画面、全画面じゃなくて微妙に小さい面積でしたよね。「こりゃ何か誤魔化してるな」と思った記憶も。面積を小さくして何かを ―― たぶんVRAM転送時間を稼いでたのでは、と。

メガドラって、16bitがどうとか、マリオとソニック比べてこんなに速いとか謳ってましたけど、実は色々と遅いのだろうと思うのですよ。PCエンジンのCPUより遅いという話もあったし…。さすがにスーファミのCPUよりはホントに速かったらしいけど。

で。もしかしてシルフィードのポリゴン描画って、その「画像変形機能」を使ってたのかなと。

ベタ塗り画像を元画像として、ソイツを変形させて描画すれば、ソレって見た目は生ポリゴンに見えるはず。極端な話、元画像はもしかすると1ドットで済んじゃったかもしれない。1ドットを四角形扱いして、変形拡大描画をすれば、ポリゴンを塗りつぶしてるように見せかけることができる、みたいな。

だけどそれで5000ポリゴンも描けるものかな？ 当時のハードだぜ？ と疑問が湧くのだけど。描画面積や、元画像の大きさに応じて、処理時間が変わってくるハードウェアだったとしたら…。小さい変形四角形の塗り潰しを繰り返すだけなら、要するに、トータルの描画面積さえ少なければ、そこまでイケる瞬間があったのかも。

それにそもそも、60FPSで描画してないし。15FPS前後なら、1フレームあたりで使える時間は長くなるから…なんとか間に合ってくれるのかも。

まあ、上記は全て想像でしかないので、実際どうなのかは分からんのですけど。

その追加機能の実力って、こっちは分からんですからねえ…。こっちが最終的に目にできるのは、おそらくVRAM転送で足を引っ張られたガクガク映像だけだし。だけど、あの回転拡大縮小機能ってのは、実は意外と結構できるヤツだったのかもしれない。

だとすると…。「ムービー垂れ流しゲー」なんてとんでもない誤解だなと。3D計算の結果をひたすらCD-ROMから読み込んで、追加されたハードウェアをビシビシ叩いて、画像変形描画をポリゴン描画に見せかける頓智を延々と繰り返し、亀のように遅いメガドラのVRAM転送を通じてTV画面に出して、また次のフレームの描画に取り掛かる…。

これは、動画プレイヤーというより、3Dモデルビューワに近いかも。

もしそうなら、たしかに正真正銘、「リアルタイムにポリゴン描画」してますわな。嘘はついてない。ただ、一番ヘビーな3D計算処理をすっぽかしてるあたりがミソ。

「よいか、MEGA-CDよ。お前はバカなんだから計算しなくてよろしい。その代り、このデータ通りにポリゴンを描け。ひたすら描け！」「イエッサー！」と単純作業に専念させたから、あの映像が実現…したのかもしれない。

本当にそうかな？ ステージによっては、動画データを展開してるように見える時があったりもするような…？ まあ、ステージごとに処理が違う可能性もありますよね。全ステージで同じ処理をしなきゃいけない、なんて法律があるわけでもなし。

それにしても。ン十年も経ったのに、「どうやって実現したのか未だにハッキリしない」ってのはなんだか凄いなと。

もちろん、知ってる人は、ちゃんと仕組みを知ってるのでしょうけど…。

ツッコミ欄で「シルフィードの背景動画を再生できるツールがある」と教えてもらえたので試してみました。情報thxなのです。

_2014/12/30 MEGA-CD版シルフィードの背景動画を再生

結論だけ書いておくと…。コレ、どう見ても動画ですな！