しかし、今回つまづいたのはそんなことじゃありません。 実は前回の続きなんです。そう、「回転」ですね （そういえば、前回「三角関数同士の積のテーブルを使う」てな方法を とりましたが、やっぱり「加法定理」を使ったほうがよさそうです）。

「行列の計算が面倒ですな」ということで、「行列の合成結果を出力するプログラム（Sin,Cosなどを用いた文字列で）」を作成し、 それを元に考えたんですが、結局あってるか不安になって「手」で計算したり...（プログラムの結果もちゃんとあってました）。 そんなこんなで二時間くらいかかってしまいましたが、なんとかできました（計算はね）。 それにともない、Y軸もディスプレーにあわせるのではなく、左手座標系に準拠させました。 （理由は回転が左回りにならなかったからです。）

で、計算上、すべてうまくいきました。しかし、ここで落とし穴があるのがプログラムです。 僕は見事に落ちました。それは、「さも計算がうまくいってないようにみせることができる」 描画部分でした。

僕の描画ルーチンは、なんか描画情報をもってる構造体をレンダリングエンジン（というと大げさだけど）に 渡すと、適当な結果をディスプレーに表示する、てな流れになってます。 描画順序は、描画情報に含まれるZ座標をもとにZソートします。ここまではいいんです。 そして、ディスプレー上での座標にX,Y,Z座標をそれぞれ変換して、 最終的に（X,Y+Z）という形でディスプレーに表示していたんです。「Z」が足しこまれちゃってるんですね。 今まではZ軸回転のみサポートだったので、Z座標は常に一定だったんです。しかし、Y,Z軸回転をサポートしたことによって Z座標に変化が.....！！そして、ずれがおきていたわけです。

では、Z座標を単純に無視するのか？そうすれば、完全横視点ゲームには都合がいいでしょうが、 NaGu-Ruは奥行き、つまりZ軸もあるので、Z座標は無視できない存在ですね。 それではどうするのか？二つ考えられます。

1.無視する
2.透視変換する

「1」は一番楽な方法ですが、実用的にだめです。「2」はうま〜く2D用にマッチするように作らなければなりませんね。 この透視変換を用いたゲームでリアルな画像になっているのに「神威」があると思います（透視変換してるかは 知らんけど、それチックなことはやってるはず。体験版を見る限りでは）。

となると、「2」をとるしかありませんよねー。今回は、X,Y,Zに大して各軸に平行移動可能で、 Y,Z軸回転をサポートした（キャラクタオンリー） 2Dゲーム、となりますね。カメラ回転はなしで、ズームイン・アウトは可能。 しかも、透視変換をやる、と。こんな感じになりますね。

しかし、そうなるとまた問題が出てきます。 それは「地面」です。地面はZ軸となす角度が0なので、完全横視点だと床が描画されないんですね。 とうことは、ちょっと斜め上から視点になるってことですか。 あと、奥へ行ったときに地面をどうするか、です。回転なしならそれなりに変形させて いかにもそれっぽくみせることは可能です（重いかもしれないけど）。