mieki256's diary

スクーターは、セグメントとセグメントの間に位置することがほとんどなので、二つのセグメントの描画位置を得て、その二つの描画位置の補間をするような感じで位置決めしているけれど…。3Dの座標を参照せず、2D座標を元にして補間しているせいか、スクーターがガタガタと動いてしまっている感じがする。

もっとも、そのガタガタ感が、スクーターの走行感を醸し出している気もするので、これはこれでアリかもしれないけれど。どうしたもんか。もっと滑らかに動くようにしたほうがいいのだろうか。でも、滑らかに動いてしまうと、滑ってる感が増しそうな気もするし…。しかし、現状では、「なんでコレ、ガタガタしてるの？」と気になりそうでもあるし…。

プレイヤーキャラに相当するスクーターについては、道路(セグメント)や木(ビルボード)を描いた後、最後に描画する感じでも問題なさそうだけど。他の車も走らせるとなると、そういうわけにはいかんよなと悩んでしまった。

道路がアップダウンする場面があるから、車が道路の奥でチラチラと見えている瞬間もあるはずで。となると、描画順を考えないと…。車を先に描画してから、道路(セグメント)と木(ビルボード)で上書き描画しないといけないなと。今は道路と木を奥から手前に向かって一気に描いているけれど、途中で車も一緒に描くような仕組みにしないと…。

さて、どうするか。各セグメントのデータ配列に、車も描画すべきかどうかを記録しておく、とか？ ただ、その場合、1つのセグメントに複数の車が登録されてしまう場面もありそう。何台ぐらい追加されるのか予測もつかないから、リンク構造にしておかないといけない気もする。ただ、その複数の車も、z値に応じて描画順が絡んでくるだろうから、z値によるソート処理が必要になるのでは…？

あるいは、全てをビルボード扱いにしてしまう手もありそうだなと。セグメント一つ一つ、ビルボード一つ一つを、描画すべきオブジェクトとしてどこかに登録していって、最後にz値でソートして奥から手前に向かって描画、みたいな。どちらのほうが楽に実装できるだろうか…。

これが昔のハードウェアなら、スプライトとBGの優先順位フラグで、このあたりをどうにかするしかなかったのだろうな…。もちろんスプライトについてはz値でソートしないといかんのだろうけど…。BGより奥にあるスプライトと、BGより手前にあるスプライト、どうやって判別していたのだろう。丘、谷、丘のような道路になった時は困りそうだけど…。