2013/11/07(木) [n年前の日記]
#2 [digital] MEGA-CD版シルフィードの謎技術についてもうちょっと想像
MEGA-CD版シルフィードの関連動画を眺めてたら、「頂点情報その他をストリーミング(CD-ROMから読み込み続ける)してポリゴン描画をしているのだ!」という説を見かけて。なるほど、それなら読み込むデータ量は少なくなりそうだな、頭いいなあ、そんな手があったか、と感心を。
でも、本当にそうなのかな? てな疑問が湧いて、またアレコレ想像を。
無駄に長いから読まなくていいですよ。自分の考えをまとめるために書き出してるだけですから…。
でも、本当にそうなのかな? てな疑問が湧いて、またアレコレ想像を。
無駄に長いから読まなくていいですよ。自分の考えをまとめるために書き出してるだけですから…。
◎ 転送量の問題。 :
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なんとかで圧縮してデータ持ってて、展開に数フレームかかった記憶があるんだけど…。圧縮アルゴリズムによっては、もっと速くできたのかな…。
表示に使うだけだから、座標値を実数ではなく整数で持っても充分だし。画面モードが 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よ。お前はバカなんだから計算しなくてよろしい。その代り、このデータ通りにポリゴンを描け。ひたすら描け!」「イエッサー!」と単純作業に専念させたから、あの映像が実現…したのかもしれない。
本当にそうかな? ステージによっては、動画データを展開してるように見える時があったりもするような…? まあ、ステージごとに処理が違う可能性もありますよね。全ステージで同じ処理をしなきゃいけない、なんて法律があるわけでもなし。
それにしても。ン十年も経ったのに、「どうやって実現したのか未だにハッキリしない」ってのはなんだか凄いなと。
もちろん、知ってる人は、ちゃんと仕組みを知ってるのでしょうけど…。
頂点情報だけストリーミングして、というやり方だと、ポリゴンの隠面消去は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よ。お前はバカなんだから計算しなくてよろしい。その代り、このデータ通りにポリゴンを描け。ひたすら描け!」「イエッサー!」と単純作業に専念させたから、あの映像が実現…したのかもしれない。
本当にそうかな? ステージによっては、動画データを展開してるように見える時があったりもするような…? まあ、ステージごとに処理が違う可能性もありますよね。全ステージで同じ処理をしなきゃいけない、なんて法律があるわけでもなし。
それにしても。ン十年も経ったのに、「どうやって実現したのか未だにハッキリしない」ってのはなんだか凄いなと。
もちろん、知ってる人は、ちゃんと仕組みを知ってるのでしょうけど…。
◎ 2014/12/30追記。 :
ツッコミ欄で「シルフィードの背景動画を再生できるツールがある」と教えてもらえたので試してみました。情報thxなのです。
_2014/12/30 MEGA-CD版シルフィードの背景動画を再生
結論だけ書いておくと…。コレ、どう見ても動画ですな!
_2014/12/30 MEGA-CD版シルフィードの背景動画を再生
結論だけ書いておくと…。コレ、どう見ても動画ですな!
*1: もしかすると本体RAMじゃなくて、内部ではフレームバッファも持ってたのかな? 本体RAMをフレームバッファとして使うのか、内部で専用のフレームバッファがあるのか、そのあたり、一ユーザには分からんですな…。
この記事へのツッコミ
[ ツッコミを読む(6) | ツッコむ ]
以上です。
管理人さんの非常に面白い思考実験にコメントされるなら、それ相当の論理的なお話しをしないと失礼です。
さて、「動画垂れ流し」の詳細が欲しいですね。
現在まで、「動画」の詳細が記載されているケースがありません。
例えば一枚一枚静止画のデータが存在するとか、こんな圧縮形式で格納されているとか。
「こちらの操作が画面に影響されるリアルタイム計算のポリゴンではなく、予め決まっている絵が画面に表示される」という意味では動画と呼んで差し支えないと思います。
問題はその中身であり、おそらく動画とは言っても今のようにmpegやH264のようなものではないのだと考えます。
私の記憶では、確かに当時の雑誌に、予め頂点計算された座標を元にリアルタイムにポリゴンを描画している「動画」だと書かれておりました。
あくまでメガCDがリアルタイムに「描画」するのであって、座標の計算はリアルタイムではないところがミソです。
この技法を、私を含め多くの人が、勝手に想像し今まで思い込むなんて不自然極まりない。
当時実際に活字になっていたから、今日「リアルタイムポリゴン描画派」が存在するのだと思います。
(しかし、ここのソースもどこにもありません。どなたか当時のbeepやメガドラFANを持っている人はいないのでしょうか・・・。)
ここからは楽しい想像のお話しですが、一般的なポリゴン座標計算で得られる(X、Y、Z)ではなく、最終結果の(X、Y)の平面座標と塗りつぶし色のデータのみをストリーミングしているのではないでしょうか?
開発機では実際に多くのポリゴン数のモデリング(これが5000ポリゴン)が動いているけど、計算結果はあくまで平面。
非常に遠くにある状態では1000ポリゴンの戦艦も、数点の頂点の白い塊になります。
しかも星の動きを見ていると、取得している座標は整数っぽいですね。
データ量は非常に少なくて済みます。
Zバッファを持たないため辺り判定は付けられないので、そこはわざわざ背景に合わせてコリジョンを持たせている。
そこに自機や敵機のリアルタイム計算のポリゴンを重ねている、と。
いやー、発売から21年経って、今なお議論されているとは!
ロマンですね〜。
動画云々はさておき、この音楽とカメラワーク、演出、今見ても文句なしにカッコイイですね。
Windowsで再生できます。
パソコンで再生できたときはゲームソフトジャケットに
記載のフルポリゴンの謳い文句が嘘だとわかりとても残業でした。
いわゆる一般的な動画コーデックで再生するツールなのか、実際のゲーム内で描画するように再生(この場合は昨今の動画ではない)するのかで違ってくると思います。
(パソコンでゆみみみっくすを再生するツールもありましたね)
当時のゲーム機で動画再生チップ内蔵はありませんので自前になるわけですが、ソフトハウスのプログラマが圧縮展開で相当苦労しているわけで。
自分もBeepメガドライブか何かで記事を読んだ記憶があります。
記事では確か頂点情報をCDから読みこんで描画していると。あと、確か当たり判定もだったかと思います。
2D座標+色情報のみ拾って描画という推察については十分ありえますよね。なるほどと思いました。
だからリアルタイム描画だけどもリアルタイム演算ではないってのはこの記事を読んだ人がそのように記憶しているのではと。
う〜ん・・・知らないとそう思っちゃうのかな・・・
「MEGA-CDの回転拡大縮小機能」はソフトウェアです
ソニックを作った中裕司さんが作った物で、発表会もありました
BIOSの中に入ってます
3D計算ですが、、メガドライブだけでも「ハードドライビン」とか「スタークルーザー」とかポリゴン表示してるソフトがあります
なので、画像を変形する機能は使ってません
メガCDが頑張って動画を再生して、メガドライブ本体がポリゴン計算する、という形ですね
覚えている内容も同じで、頂点情報と当たり判定を読み込んで〜というものでした。
なので雑誌読んでた人は皆そう記憶しているのだと思います。
問題は動画再生ツールがあるからと言っていわゆるエンコードされた動画かどうかわからない点です。シルフィードと同じような処理で動画として見れるようにしているツールの可能性も。
本当にmpegとかのような昨今の動画と同じような処理ならそれはそれですごいけどw
ウルフチームのVHDゲームの移植でも15コマも出てなかったんじゃないかな?