mieki256's diary

加減算とシフトだけでアークタンジェントが求められるらしいという話を見かけて気になったり。が、検索してもなかなかそれらしいページが見つからず。

iアプリのバグ ―― 球が障害物に当たった際に、見た目がおかしい・何もない空間で当たってるように見える ―― を解決しようと、アタリデータを検証したり、球の補正処理を追加したり等、色々作業してたのだけど。途中で、根本的な問題があることに気がついて頭を抱えてしまったり。

プロトタイプ版の背景画像は、平行投影に近い画像。その見え方を前提にして、内部ではアタリデータを用意したり、球の表示座標を算出していて、自分もソレにならってアタリデータを新規作成していたのだけど。本番用の背景画像は、パースがついてる・透視投影に近い見た目になっているわけで。

球の表示座標算出部分は、プロトタイプ版そのままなわけで…。平行投影の座標値で、透視投影の背景画像 ―― 遠くにあるものは小さく、近くにあるものは大きく見える画像に載せてるわけだから、そりゃ不自然な見た目になるわと。内部的には同じ高さの障害物であっても、アプリの実画面ではそれぞれサイズが違う障害物になっている。しかし、球は、どこにあっても同じサイズであるかのように表示してる。妙な見た目にならないほうがおかしい。

つーかなんで今頃になってこんな重大な問題に気がついたのか。＞自分。アホ過ぎる。企画参加の最初の頃に気がついておくべきじゃないか。トホホ。

では、球の表示を透視投影にしてしまうか…というわけにもいかない。それなりにパースがついてるように見える背景画像だけど、厳密に計算して作画されてるわけではなくて、部分部分で見るとパースがなかったりする。そんなところに透視投影の座標値で球を表示してしまうと、それもまた不自然になってしまう。また、アタリデータの持ち方も変えなきゃいけないし、作り直しにもなる。透視投影に必要なカメラの画角や角度の情報も判らない。大体にしてカメラの情報・透視変換前後の基準画像がちゃんとあったら、デザイナーさんが作業時に、パース云々で悩まずに済んだであろうに。

企画の最初の時点で、「パースをつけないで作画してください」等の制約を提示しておくべきだった…。かなり記憶が怪しいけど、たしか、最初の頃、パースをつけて描いて大丈夫かどうか的打診があったような気もしてきたわけで。だけどその当時、おそらく自分は、「そのへんなんとかなるだろ」と甘く見てたんだな…。トホ。

ということで自分なりの結論。

• 2Dゲームを作る際には迂闊に背景にパースをつけちゃいけない。BGアタリがある場合は特に。
• どうしても見た目パースをつけたかったら、3Dゲームを作る覚悟を決めること。背景画像をリアルタイムでレンダリングしてないだけ、ぐらいの気持ちで実装しないと。

とはいえ今から作り直すわけにもいかんし…。ということで、インチキ処理を実装。画面の上方に球が近づくにつれ、基準となる座標から、球と影をどれだけ上下にずらすかの値を、徐々に小さくしていくことに。これで誤魔化せるといいな…。

と、先輩プログラマーさんが以前どこかで言ってた記憶があるのだけど。まさにそうだなと。

今回弄ってるiアプリは、どうやらフラグ好きタイプの人が作ってたソースのようで。とにかくフラグだらけ。どこでどのフラグが立つと、どこでどんな処理が行われるのか、さっぱり把握できず。ステップ好きの自分には、何がなんだかわからない…。フラグ好きのタイプの人は、頭がいいんだな…。