2008/05/27(火) [n年前の日記]
#1 [iappli] 8bit〜16bitPC時代の3Dっぽいゲーム画面を検索
携帯アプリと言えども3D画面にするならせめてそのくらいの見た目にしないとダメだろう、という気がしてきたのでアレコレ探してみたり。昔の非力なハードで、どこをどうやって誤魔化しつつ、しかしどこらへんまでは真面目にやってたのかな、みたいなあたりを、たとえ漠然としたレベルであっても一応把握しておきたいと。つーか遠景の扱いをどうしたものかイメージが湧かなくて。＞自分。
SFCでも該当ジャンルのタイトルはあったらしいのだけど。3Dでそれっぽくレンダリングするのに3秒ぐらいかかってた、という話も見かけた。キツイな。そうなってくると、ユーザに方向を決めてもらう際に、視線の向きを変える＝その都度リアルタイムに風景をレンダリングするのではなく、時間をかけて風景をレンダリングしたその上に、方向だけを示す矢印等を上書き描画する、ような見せ方のほうがいいのかもしれない。
1枚の風景画像の描画に時間をかけていいのであれば、かなりリアルな画面にすることも、おそらくは可能なはず。携帯側に用意されてる、汎用性のある3D描画機能を使わずに、自前で、そのジャンルに特化したレンダラー(?)をゴリゴリ記述して、そのジャンルに特化したデータを持たせて…。
ただ、大昔にゲーセンで見た、二軸回転？ 平面での描画のみではあるけれどグリグリとリアルタイムに視線の向きが変わる某K社の某ジャンルのタイトル、を見かけた時の感動を思い返すと…。仮にショボイ画面でも、リアルタイムにグリグリと動いたほうが「おおっ」と思うのではないか、という感もあって。というか今時出てるタイトルも、おそらくは大体がそういう方向で作ってるのだろうし。そういう状況の中で、見た目はリアルだけど画面が出るまで毎回数秒かかるようなものを作ってたのでは評価は厳しくなるよな。たぶん。
となると…。なんだかMDのハードドライビングみたいな画面になっちゃいそうな予感。＜オイ。
SFCでも該当ジャンルのタイトルはあったらしいのだけど。3Dでそれっぽくレンダリングするのに3秒ぐらいかかってた、という話も見かけた。キツイな。そうなってくると、ユーザに方向を決めてもらう際に、視線の向きを変える＝その都度リアルタイムに風景をレンダリングするのではなく、時間をかけて風景をレンダリングしたその上に、方向だけを示す矢印等を上書き描画する、ような見せ方のほうがいいのかもしれない。
1枚の風景画像の描画に時間をかけていいのであれば、かなりリアルな画面にすることも、おそらくは可能なはず。携帯側に用意されてる、汎用性のある3D描画機能を使わずに、自前で、そのジャンルに特化したレンダラー(?)をゴリゴリ記述して、そのジャンルに特化したデータを持たせて…。
ただ、大昔にゲーセンで見た、二軸回転？ 平面での描画のみではあるけれどグリグリとリアルタイムに視線の向きが変わる某K社の某ジャンルのタイトル、を見かけた時の感動を思い返すと…。仮にショボイ画面でも、リアルタイムにグリグリと動いたほうが「おおっ」と思うのではないか、という感もあって。というか今時出てるタイトルも、おそらくは大体がそういう方向で作ってるのだろうし。そういう状況の中で、見た目はリアルだけど画面が出るまで毎回数秒かかるようなものを作ってたのでは評価は厳しくなるよな。たぶん。
となると…。なんだかMDのハードドライビングみたいな画面になっちゃいそうな予感。＜オイ。
◎ 参考資料を眺めたり。 :
昨日キャプチャした実写画像や、昔のその手のゲームのスクリーンショットを眺めた感じでは、遠景は木で覆い尽くしてる感じ。となると、木の描画＝ビルボードがどれだけ大量に描画できるか、という話になってくるのかな…。
Dojaのソレには、ポイントスプライトというビルボードっぽいものがあるけれど。それはZバッファ関連処理の対象にはならず、ポリゴンプリミティブを一旦全部描画した後で、その手前にポイントスプライトがごっそり上書き描画される状態になるらしく。つまり、地形でチラチラと隠れるかもしれないビルボード、としては使えない…。
すると、ビルボード一枚一枚を、ポイントスプライトではなく、ポリゴンプリミティブとして、設定することになるのだろうか。いや、しかし、地形モデルデータの描画と、自前で一つ一つ設定したプリミティブは、描画の流れが一旦分断されてしまう＝地形でビルボードが隠れない or 地形でビルボード全体が軒並み隠されてしまうのでは、という不安も。ということは、地形モデルデータをそちらで描画しておくれ、と指定するのではなく、地形モデルデータのポリゴン一枚一枚をプリミティブとして設定して描画するようにしてやらないといかんのだろうか。しかしそんなことをしたら、描画処理時間がべらぼうに増大してしまう可能性が。うーん。
であれば、十字に配置したビルボード代わりのポリゴンを、事前に地形モデルデータに付加してしまうやり方になるのかな。が、しかし、それをすると一本の木を描画するのに2枚のポリゴンを使ってしまうので、木の本数分、ポリゴン枚数が倍増してしまう。これもこれで描画処理時間が増大しそう。うーん。
一枚一枚描画指定をするか、事前にモデルデータに含めておくか、どっちのほうがまだマシか、ということになるのだろうか。しかし、下手すると、機種によってはそのへんの負荷の量が逆転したりする可能性も…？ ううーん。
テクスチャをどうするかという問題もあるんだよな…。自然の風景のそれだから、できるだけ細かいテクスチャにしたいけど。それをするとテクスチャ画像が大きくなる＝容量を使ってしまう。テクスチャの繰り返し回数を指定することはできないのだろうか。それができると非常に助かるんだけど。
Dojaのソレには、ポイントスプライトというビルボードっぽいものがあるけれど。それはZバッファ関連処理の対象にはならず、ポリゴンプリミティブを一旦全部描画した後で、その手前にポイントスプライトがごっそり上書き描画される状態になるらしく。つまり、地形でチラチラと隠れるかもしれないビルボード、としては使えない…。
すると、ビルボード一枚一枚を、ポイントスプライトではなく、ポリゴンプリミティブとして、設定することになるのだろうか。いや、しかし、地形モデルデータの描画と、自前で一つ一つ設定したプリミティブは、描画の流れが一旦分断されてしまう＝地形でビルボードが隠れない or 地形でビルボード全体が軒並み隠されてしまうのでは、という不安も。ということは、地形モデルデータをそちらで描画しておくれ、と指定するのではなく、地形モデルデータのポリゴン一枚一枚をプリミティブとして設定して描画するようにしてやらないといかんのだろうか。しかしそんなことをしたら、描画処理時間がべらぼうに増大してしまう可能性が。うーん。
であれば、十字に配置したビルボード代わりのポリゴンを、事前に地形モデルデータに付加してしまうやり方になるのかな。が、しかし、それをすると一本の木を描画するのに2枚のポリゴンを使ってしまうので、木の本数分、ポリゴン枚数が倍増してしまう。これもこれで描画処理時間が増大しそう。うーん。
一枚一枚描画指定をするか、事前にモデルデータに含めておくか、どっちのほうがまだマシか、ということになるのだろうか。しかし、下手すると、機種によってはそのへんの負荷の量が逆転したりする可能性も…？ ううーん。
テクスチャをどうするかという問題もあるんだよな…。自然の風景のそれだから、できるだけ細かいテクスチャにしたいけど。それをするとテクスチャ画像が大きくなる＝容量を使ってしまう。テクスチャの繰り返し回数を指定することはできないのだろうか。それができると非常に助かるんだけど。
◎ ドキュメントを眺めてみた。 :
ポリゴンプリミティブは、一旦描画指定バッファに溜めこんで、後で一気に描画する、と書いてあるな…。ということは、地形モデルデータとは別に、ポリゴンプリミティブでビルボードが実現できる可能性がある？ ということ？
[ ツッコむ ]
以上、1 日分です。