たけなか制作日誌

ようやく実際のプレイ画面をキャプチャして動画にしてみました。
ただ実際プレイしているときは音声がついてますが、一応
音声の方は版権うんぬんがあるのでカットしています。

4月1日なので、動画くらいなら。。いいですよね苦笑。
ちなみに実際の音声は、試験的にまやろーやるさんの曲を
流していたりします。透き通った歌声がとても心地いい感じです。
リンクから各自脳内補完でよろしくお願いします笑。

実をいうと、本当はもっとクオリティをあげたかったんですが、
やっぱり色々やることが多くて大変ですね。なので、ちょっとずつ、
自分の思い通りのクオリティに近づけていこうかと思います。

長い間苦戦していた背景クラスがようやく完成というところまで来ました。

時間がかかったのは、今まで勉強してこなかった衝突判定を山のように
使用することになったからなのですが、おかげで以前より大分衝突判定に
強くなったので、とりあえず良しとしよう笑。

今回は簡単な動画を用意しようかと思ったけど、まだモーション
切り替えやモデルの半透明描画を実装してないんですよね。他には
モデル間の衝突判定や、メニュークラスも手すらつけていない状態なので。。

やればやるほど先が長いのが見えてくるなあ苦笑。

最近になって、ようやくある程度見栄えがいい感じになりつつあるので、
そろそろ動画でも作って公開してみようかなと思ったんですが。
背景クラスを作成しないと、ニッチもサッチもいかない感じでしたので
現在はもっぱら背景クラスの制作中です。

とりあえずとっかかりとして指定したポリゴン内にオブジェクトが
存在しているかどうかをできるようにしてみました。これを利用して
そのポリゴンから高さを求めたり、頂点カラーを取得して
場所によって明るくしたり暗くしたりできるわけです。

まあ、やってること自体はすごく単純なことなんですが。
一番問題になってくるのが、当たり判定用のメッシュのポリゴン数が
多い場合、モデル位置のポリゴンを検出する時間がどんどん
大きくなってしまうので、どうしようかなと色々考えた末、一定区間ごとに
当たり判定用メッシュのインデックスをデータベース化する
ことにしました。

今のところは当たり判定用メッシュ読み込み時のデータベース化の
プログラムが組み終わったかなというところです。それと実は
もう一つ、ポリゴンの検出回数を減らすための工夫を追加する予定
なんですが、これは話が長くなりそうなので今は秘密にしておきましょう笑。

早く動画まで行けるといいなあ。

とりあえず早くフレームワーク部分の制作を終わらせて
実際のプレイ部分のコーディングに進みたかったので、
サクサクっとテキストスプライトとサウンドを導入してみました。
…という割には更新が若干遅れ気味ですが苦笑。

サウンドはDirectSoundで導入してみて、mmioを使用して
導入した関数とmmioを使用せずに導入した関数の2つを
一応用意してみたんですが、2つ試した感想としてはmmio関数を
使わない方が直感的な感じがしなくもないかな笑。

とりあえずこれで後は当たり判定をいれたら大体卒制と同じものが作れる
…と思ったんですが、そういえば肝心のアニメーションの
切り替えを実装し忘れてました。。

いかんいかん！モーション切り替えは早めに実装しようと思います。

ようやくシェーダでスキンメッシュができるようになりました。
ようやく、ようやくですよ！長い道のりでした。

とりあえずCPUスキンメッシュとどのくらい処理速度が違うのか
計測してみましたが、早いです！やっぱりGPUは偉大だなと思いました。

以下少し比較めも＆ちょっとした考察です。

・CPUスキンメッシュ(1/2モーションスキップ)、キャラ5体：50fps
・CPUスキンメッシュ(1/2モーションスキップ)、キャラ10体：28-30fps
・シェーダスキンメッシュ、キャラ5体:60fps
・シェーダスキンメッシュ、キャラ10体:53-55fps

今まで5体までしか表示してませんでしたが、試しに10体表示させてみると
やはり全然違ってきますね。それとパーティクルは現状、CPUで頂点計算
させているので、シェーダ有りでも10fpsほど落ちてしまうんですが、
これもシェーダで計算させるとまだ速度が上がるかもしれないです。

ただ、長い時間PCを使い続けているとなぜかCPUスキンメッシュと
シェーダスキンメッシュが同じくらいの速度(30fps近く）に
なってしまいました。PCを使い続けるとメモリが断片化して
処理効率が悪くなるのは前から気がついていたんですが、
シェーダ有り･無しとで速度が同じになるのは少し疑問だったりします。

そういえば、いままでDraw系命令を呼び出した直後に
GPUに描画命令が転送されているものだとばかり思ってましたが、
どうやらDraw系命令やSetRenderState系命令を行うと、
一度コマンドバッファと呼ばれるGPUでの命令手順を格納した
バッファにプッシュして、Present()を行うことでまとめて
命令とデータをGPUに転送しているんだそうです。なので
それによって実際はフレーム計算をしている間GPUは並行して
1つ前のフレームの描画を行ってるんだそうな。

てことは、以前考えていた「マルチスレッドにすることでGPGPUと
同じ理屈で処理が早くなるんじゃね？」というアイデアは意味がないですね。。
ただ、Lock()はその時点でGPUにアクセスしなければならないので
GPUがそのバッファを描画に利用していた場合、CPUは待機させられるそうです。

ということは！パーティクル計算が現在重いのはCPUで頂点計算を
させる際、待機させられているから処理が重くなっている可能性が高いので、
バッファを複数用意して、奇数フレーム用バッファと偶数フレーム用
バッファといった感じでバッファを使い分けることで、シェーダを使わずに
少しは処理速度が上がるんじゃないかなと、ふとそう思いました。

ただ、これだとバッファのための確保サイズが2倍になるので、
素直にシェーダでやっとけといわざる終えません！笑

最近は色々な実装を平行して作業したりしていて、片手間に
固定機能パイプラインのスキンメッシュを試してみたのですが、
色々と試行錯誤した点が多かったので以下めも。
(横文字がいつもより多くて非常に読みづらいので注意です！)

今までCPU計算でスキンメッシュさせていたやり方に
SetRenderState()のD3DRS_VERTEXBLENDフラグと
D3DRS_INDEXEDVERTEXBLENDENABLEフラグを使用して、
D3DTS_WORLDMATRIXに各フレームのスキニング行列を
設定してみると固定機能パイプラインで描画できるかなと考えたんですが。。
デバッグ中に、「あんさんのPCはD3DRS_INDEXEDVERTEX
BLENDENABLEをサポートしとらんよ」っていわれてしまいました。

そこでデバイス作成時のオプションをD3DCREATE_HARDWARE_
VERTEXPROCESSINGからD3DCREATE_SOFTWARE_
VERTEXPROCESSINGに変更してインデックスつきで
スキンメッシュ描画が無事できるようになったのですが…重い。
重すぎるのです。。キャラ１体表示させるだけでも20fps
程度しかでない、つまり自前CPU計算より何倍も重いんですよ。

後からWEBで色々と調べてみたところ、どうやらDirectX9系の
グラボはシェーダで描画することを推奨しているので、MaxVertex
BlendMatrixIndex(最大ブレンドマトリックスインデックス数)が
0のグラボが多いそうです。。なので、「スキンメッシュやるくらいなら
シェーダ使いんさい！」ってことらしいです。

DirectX9系以前のグラボの場合はD3DRS_INDEXEDVERTEX
BLENDENABLEフラグを使って固定機能パイプラインで描画したり
したほうが安定するんでしょうけど、対応させようにも自分の
環境だとデバッグすらできませんからね。。

今までネットでスキンメッシュについて調べていて、「なんで
みんな描画時に複雑な分岐フラグを立てて描画してるんだろう」と
思ってたんですが、ようやく分かったような気がしました。

とりあえずシェーダ対応ならシェーダで計算、シェーダ未対応なら
自前CPUで計算という形でプログラムを組んでいこうと思います。

頑張った甲斐もあって、C++とDirectX両方のメモリリークエラーを
無事なくすことができました！ふう、疲れた。

そういえば、デバッグレベルを上げるとおそろしく処理が重くなりますね。
スプライトを数枚表示させるのでも30fpsしかでませんでしたよ。。
それと、メモリリークエラーを回避できた後に気づいたんですが、
メモリリークが発生してるとデバッグ時のプログラム終了が極端に
遅くなります。なので「なんだかデバッグの終了が遅いなあ」と
思ったらおそらく十中八九、メモリリークのチェックに時間が
かかってると考えていいのかなと思いました。

後はデバッグ中、デバッグウィンドウに山のように表示される
SetRenderState()等の警告を消すだけなのですが。
これってネットで調べてみると内部処理で同じ設定の場合は
スキップするようになっているようなので、自前でわざわざフラグを
たてる必要は本当はないらしいんですよね。。

けどじゃあなぜ警告がでるんだって話なんですが。。
とりあえずデバッグがとてもしづらいので自前のスキップ処理を
きちんとやっておこうと思います。

今までデバッグについては、「とりあえずビルドが通ればそれでいいや」と
いった程度に考えていたんですが。_CrtSetDbgFlagを使って
メモリリークをチェックしてみると、かなりの数のメモリリークが
発生していることが分かりました。。

それでとりあえずDirectXのデバッグレベルを上げてチェックしてみると、
でてくるでてくる、エラーや警告の山！スプライトだけでチェックして
いるにも関わらず、エラーの数が多すぎて正直うんざりしてきます。

どうやらSetRenderState()を同じ設定で重複させても
警告がでるみたいで。本格的にデバッグをやろうと思うとかなり大変そうです。。

とりあえず、警告は無視してメモリリークだけエラーを回避すべきか。

パーティクルです！めらめら。

ここ最近はパーティクルシステムの作成にかかりきりでしたが、
とりあえず基本的な機能だけは無事実装させることができました。
しかし、パーティクルのソートがとにかく重いです。。現在は
バブルソートでソートしているのですが、30fps程度しかでなくなりました。

なので、実はパーティクルシステムと平行してこっそりと
SIMDの勉強をしていたりします。いまのところCPUばかり
酷使しすぎなんですが、あわよくばCPU・GPU共に
最大限機能を活かしたいところです。

今のところSIMDをサポートしているかチェックする部分だけ
搭載させているのですが、果たしてSIMDを使うところまでいけるかどうか。。
そもそも、僕のCPUだとSSE2までしか搭載していないし、
それ以上の命令を搭載させようにもデバッグすらできないという苦笑。

今までやろうやろうといいつつやっていなかったアニメーションバッファの
ストック＆再利用を試してみることにしました。
…はい、最近地味な作業ばかりが続いております。

とりあえずはじめはDirectXのバッファ型ではなく、自作の
頂点用構造体を利用して配列でバッファを作ってみたんですが。。
これがなぜか、45fps→40fpsと逆に速度が遅くなってしまったのです。

色々悩んだ末、ひょっとしたらD3DPOOL_SYSTEMMEMはただ
物理メモリに作成するのではなくて、GPUにアクセスしやすい
位置(？)に格納しているのではないかなと思い、今度は
DirectX本来のバッファ型で作成してみると、今までMAXで48fpsまでしか
でなかったのが、とりあえず50fpsまででるようになりました！
たかだか数fpsなんですが、50fpsまでいくと今までの地道な努力が
少しは報われたような気がします。当初はたったの20fpsでしたからね苦笑。

結論からいってしまうと、CPUで計算するかGPUで計算するかなんて
ほとんどどうでもいいくらい、CPU-GPU転送にかかる時間は
馬鹿でかいってことなんでしょうね。

それとストックバッファを利用してプログラムを数分起動していると、
なぜだかFPSが不安定になってプログラムのウィンドウが消えるという
症状が何度も発生してしまいました。おまけにVCもフリーズして
デバッグ結果が分からないという。。

おそらくはLock(),Unlock()を間髪入れずに何度も使用しているので
CPU-GPU間のアクセスでエラーが発生したのではないかなと
思うんですが、とりあえず原因はこれから調べるところです。

今まで、「こんな部分でエラーなんてでないだろ」と思って、
エラーチェックを外している部分が多かったんですが。。
ここに来てツケが回ってきやがりました。急がば回れ、と。

それと、色々と調べているうちに固定パイプラインでのスキンメッシュの
描画方法がなんとなく分かってきたので、これも近いうちに試してみて、
上手くいった場合はストックバッファなんて変な実装をやらずに
固定パイプラインで描画しようと思います笑。