ゲーム制作の舞台裏

サンプルプロジェクト実行画面
以前と同様のサンプルプロジェクトを作成して、パフォーマンスを比較した。意外と遅い？

---

◎動的頂点バッファ

XNAのモデルインスタンシングについて調べていたら、DynamicVertexBuffer（動的頂点バッファ）に関する記事を見付けました。頂点データの動的変更は、これを使った方が速くなるかも…？

というわけで、インスタンシングの前にこれをやります。



◎SetDataのエラーと対処

DynamicVertexBufferに関する記事はちらほら見かけるのですが、シンプルなサンプルはなかなか見当たりません。そこで、ソーサリーフォースのIndexBufferサンプルを自力でDynamicに改修することにしました。

まず、VertexBufferやIndexBufferを単純にDynamicVertexBuffer等に置き替えると…



エラーもなく普通に動きました。（ちょっと意外ｗ）


次に、頂点データの内容を動的に変更すると…SetDataでエラーが発生しました。

操作は中断されました。デバイスで設定されているリソースは変更できません。また、タイリング ブラケット内で使用した後に変更することもできません。

以前発生したのと同じエラーですが、今回はDynamicVertexBufferを使用しているので対処可能です（こちらの記事によると、SetDataOptions.NoOverwriteが良いらしい）。

this.vertexBuffer.SetData(vertives, 0, vertives.GetLength(0), SetDataOptions.NoOverwrite);



時間経過と共に、頂点が上方向に移動しました。
成功ですねｗ

ちなみに、今回はSetDataOptions.Discardとしても結果は一緒でした。モデル数や頂点数で違いが出るのかな？



◎パフォーマンス比較

以前と同様のサンプルプロジェクトを作成して、パフォーマンスを比較しましょう。

…で、実際に作ってみると、ちょっと悩ましい点が出てきました。

・バッファ領域を全インスタンス分確保すべきか？
　→多分その方が早いので、全インスタンス分確保する

・頂点／インデックスデータを毎回取得／設定すべきか？
　→公平に比較するため、前回同様毎回取得／設定する

そもそもデモ内でインデックスデータは変更してないので、インデックスデータの取得／設定は全く無駄なんですが、実際のゲームに適用する場合を考慮して以前のデモに組み込んでしまったので、今回も同様の想定としました。

よく考えると、頂点データを変更してもインデックスデータは変更しないケースの方が多い気がしますが…まぁいいかｗ



　　シェーダー改修方式 → 今回方式
板ポリアニメ 100枚：60 → 60(fps)
板ポリアニメ1000枚：59 → 38(fps)
板ポリアニメ1500枚：40 → 30(fps)
板ポリアニメ2000枚：30 → 20(fps)
板ポリアニメ3000枚：20 → 15(fps)
板ポリアニメ5000枚：15 → 10(fps)

ありゃ？遅くなっちゃった？
と言うか、これまでで一番遅いですね…。



◎バッファ更新タイミングの変更

頂点データとインデックスデータを毎回バッファにセットしてるから遅いのかもしれません。アニメ画像番号が更新された時だけ、バッファ操作するように修正しましょう。

　　　　　　 改修前 → 改修後
板ポリアニメ 100枚：60 → 60(fps)
板ポリアニメ1000枚：38 → 59(fps)
板ポリアニメ1500枚：30 → 30(fps)
板ポリアニメ2000枚：20 → 23(fps)
板ポリアニメ3000枚：15 → 15(fps)
板ポリアニメ5000枚：10 → 9(fps)

1000枚はシェーダー改修方式と同等まで改善されましたが、1500枚以上は大差無いようです。1000枚超えたあたりを細かく測定してみました。

板ポリアニメ1050枚：58(fps)
板ポリアニメ1080枚：50(fps)
板ポリアニメ1100枚：45(fps)
板ポリアニメ1150枚：40(fps)
板ポリアニメ1200枚：30(fps)

ふむ…1000枚を超えたあたりから急に遅くなるのは間違いないようですね。もしかして、1024枚を超えるとGDCメモリを超えてスワップが発生するとか？でも、バッファメモリが足りなければ領域確保時にエラーになりそうだけどなぁ…。

以前の方式と今回の方式をPIXで細かく比較すれば、原因がわかるかもしれませんが、わかった所で以前の方式を超えることは出来ないので、この点に関してはこれ以上追及しないことにします。



◎以前の方式を超えられない理由

シェーダー改修方式のようなイレギュラー方式はともかく、DrawUserIndexedPrimitives方式よりも遅い理由は把握しておきたいですね。予想としては、頂点データの更新頻度が頻繁すぎるからじゃないでしょうか？

アニメは80ミリ秒毎に更新するので、Draw()呼び出し（約17ミリ秒毎）５回毎に、バッファを１回更新することになります。ということは、「DrawUserIndexedPrimitivesで５回表示」と「バッファ更新＋DrawIndexedPrimitivesで５回表示」のどちらが早いか？を比較していたことになり、「後者がやや遅い」と仮定すれば、これまでの計測結果が納得できます。

では、この仮説が正しいか検証しましょう。アニメの更新頻度を変更して、両者のパフォーマンスを比較します。

○アニメ更新頻度：80 → 160
　　　　　　 DrawUser〜方式：今回方式
板ポリアニメ 100枚：60 → 60：60 → 60 (fps)
板ポリアニメ1000枚：59 → 59：59 → 59 (fps)
板ポリアニメ1500枚：30 → 30：30 → 30 (fps)
板ポリアニメ2000枚：30 → 30：23 → 30 (fps)
板ポリアニメ3000枚：20 → 20：15 → 20 (fps)
板ポリアニメ5000枚：12 → 12： 9 → 10 (fps)

○アニメ更新頻度：80 → 500
　　　　　　 DrawUser〜方式：今回方式
板ポリアニメ 100枚：60 → 60：60 → 60 (fps)
板ポリアニメ1000枚：59 → 59：59 → 59 (fps)
板ポリアニメ1500枚：30 → 30：30 → 30 (fps)
板ポリアニメ2000枚：30 → 30：23 → 30 (fps)
板ポリアニメ3000枚：20 → 20：15 → 20 (fps)
板ポリアニメ5000枚：12 → 12： 9 → 12 (fps)

DrawUser〜方式は、更新頻度を下げてもパフォーマンスが変化しなかったのに対し、今回方式は、更新頻度を下げるとDrawUser〜方式と同等のパフォーマンスになりました。

この結果だけで決めつけるにはデータ不足とは思いますが、先程の仮説は正しい気がします。（多分ｗ）



◎まとめ

今回の結果だけを見ると、動的頂点バッファ方式はDrawUserIndexedPrimitives方式を超えられません。但し、別のケースであれば逆の結果になる可能性もあるはずです。

予想としては、

・頂点／インデックスデータを頻繁
　（80ミリ秒以内毎）に更新する場合
　→DrawUserIndexedPrimitives方式が良い

・頂点／インデックスデータを時々
　（160ミリ秒以上毎）更新する場合
　→動的頂点バッファ方式が良い

・頂点／インデックスデータを全く更新しない場合
　→通常のDrawIndexedPrimitives方式が良い

こうなることを期待していましたが、動的頂点バッファ方式が良いケースを実証できなかったのは残念ですね。


それと、私のPCでは1000枚を超えると急激にパフォーマンスが低下するらしく、1500枚で30fpsを超えられるのはシェーダー改修方式だけのようです。どの方式にも長所短所があるはずですが、あの方式の短所って何かなぁ？



◎サンプルプロジェクト

とりあえず今回のサンプルプロジェクトをHPにUPしました。なるべくシンプルにまとめたつもりですのでご参考まで。

XNA3.1でUVアニメーション（動的頂点バッファ方式）



◎次回予告

「動的頂点バッファ」という言葉が何となくカッコ良くて、ちょっと憧れていたのですが、今回はその効果が実感できなくてちょっとガッカリ。どうすればその効果が見えるようになるんですかねぇ？

それはともかく、次回からモデルインスタンシングです。
…って前回も言ったなぁ（汗）

テーマ : ゲーム製作　関連 - ジャンル : ゲーム

徐晃出陣
于禁の七軍が壊滅してしまったため、宛に駐留中の徐晃に樊城救援の命が下った。重大任務を果たすべく、決意を固めて出陣する徐晃。

---

◎１月の目標達成度

・活動時間月120時間以上

実績：120h（達成率：100%）

　（中間目標：1/20迄に60h以上）

実績：60h（達成率：100%）


・画像ファイルの統合（10h）

実績：50hで完了（達成率：100%）


・企画見直し（24h）
・全体スケジュール見直し（12h）
・マップオブジェクト属性読込、表示（24h）

実績：未着手（達成率：0%）


・ブログ更新／HP更新（40h）

実績：54hでブログ更新、HPに「XNAのBasicEffectをカスタマイズ可能とする」「XNA3.1でUVアニメーション」など３記事を追加（達成率100%）

・その他（10h）

実績：13hでCG監修等実施（達成率100%）


・予定外の作業

実績：3hでインスタンシング調査 作業中


前半はボロボロでしたが、後半はそれなりに頑張ったと思います。でも進捗はいまいちですね〜。



◎作業時間分析

作業時間集計2010年1月（PDF形式）


○良かった点
・後半頑張って、活動時間月間目標を達成した
・HP記事を8hで３件登録した

○悪かった点
・前半の活動時間が非常に少ない
・「画像ファイルの統合」が目標時間を大幅に超過した
・ブログの時間が多い（理想は30%以内）


大戦略Webの影響で前半ボロボロでしたが、引退後はペースを取り戻しつつあります。HP記事を8hで３件登録した頃は集中できていたので、集中時間帯が増えるよう頑張ります。



◎画像ファイルの統合について

１月の目標を決めた段階では、統合後の画像表示を深く考えてなかったので、画像を１枚にまとめるだけで10hと考えていました。

ところが、実際に画像を統合してみると、そのままでは全く表示できません。大戦略Webに気を取られていたとはいえ、そんなことに気付かなかったとは我ながら情けない（＞＿＜）


元々の予定では、画像統合やインスタンシング等の高速化はゲーム全体がある程度出来あがってから実装するつもりだったのですが、画像を統合した以上、表示しないと意味無いので、そのまま表示プログラムに突入しました。

表示にはテクスチャ座標の動的変更が必要です。これは１年前からやりたくて出来なかったテーマの１つですが、これが出来るようになったのは、私のXNAスキルがそのレベルまで向上したからだと思います。

しかし、実装に伴い遅延現象が発生し、原因究明にかなり時間を要してしまいました。まだまだ精進せねばなりませんね。



◎進捗状況チェック

スケジュールは凍結中です。

画像統合までやってしまったので、インスタンシングでどこまでパフォーマンスが出るか様子を見てから、企画とスケジュールの見直しを行います。



◎２月の目標

・活動時間月144時間以上
　（中間目標：2/15迄に72h以上）

・インスタンシング調査／解析／実装前検証（48h）

・インスタンシング実装／計測／調整（40h）

・ブログ更新／HP更新（48h）

・その他（8h）

インスタンシングは手強そうですし、やりたいことも多いので、時間配分を多めに設定しました。作業時間の効率化を図るよりも、パフォーマンスを高めることに集中したいですね。



◎次回予告

というわけで、次回からいよいよモデルインスタンシングです！

テーマ : ゲーム製作　関連 - ジャンル : ゲーム

開発中のメイン画面
低解像画像に差し替えたら、遅延現象が解消された。木の画像はGIMPで縮小したものを使用している。

---

◎エフェクトの使い回し

前回の遅延原因調査の続きです。

特に工夫もなく何百枚ものテクスチャを差し替える旧方式が遅延せず、前回のテクスチャアトラスで遅延が発生するのはどうしても納得できません。あれこれ悩んで、ある仮説に至りました。

前回、画像の数だけモデルとエフェクトを用意したのは、Draw()内のエフェクトパラメータ変更を最小限に抑えるためです。しかしエフェクトがグラフィックデバイスのレンダーステートパラメータセットだとしたら、エフェクトを増やすとパラメータ変更が大量発生することになります。

それよりも、１つのエフェクトを使い回して、一部のパラメータ（テクスチャ指定など）をDraw()内で動的に変更した方が、パラメータ変更負荷が減るのではないでしょうか？

で、実際にやってみたら…変化なし。どうやらこれも違うみたいです。



◎ミップマップの有無

次に考えた仮説は、１枚あたりのテクスチャ解像度が増えたために、CPUメモリからGPUメモリへの転送に時間がかかる、ということです。

だとすると、ミップマップを有効にすれば画像解像度が自動選択されるので、遅延を解消できるかもしれません。

ミップマップ設定を確認すると、旧方式も前回方式も「モデル：有、テクスチャ：無」でした。前回方式のテクスチャミップマップを有効にすると

6 → 2 (fps)

さらに低下してしまいました（爆）



◎画像解像度の変更

ここでyohさんから「テクスチャやエフェクトがGPUメモリに収まりきらなくてスワップが発生してるかも」とのコメントを頂きました。

エフェクトに関しては、今回冒頭で試してダメだったので、違う気がします。また、連画取得時の解像度を下げてテクスチャの総データ量を大幅に減らしたので、テクスチャの総データ量も関係ありません。そうなると考えらるのは、やはり「１枚あたりのテクスチャ解像度が増えたから」でしょうか？

ミップマップ設定ではなく、元画像の解像度を変えないと意味が無いのかもしれません。とりあえず、木の画像解像度を落としてみましょう。

　　　

元々2048×2048用の表示パラメータなので、画像を差し替えただけだと、カメラ位置によって表示が崩れます。パラメータ修正前と修正後それぞれ試したら、どちらも移動ユニット無しで30fps、移動ユニット有りで20fpsでした（旧方式と同じ）。

やっと遅延原因が判明しましたよ〜！！


ちなみに、連画出力ツールで512×512画像を出力して差し替えたのが左上図です。

元の2048×2048画像をGIMPで512×512に縮小した画像に差し替えたのが右上図です。

低解像オリジナルよりも、高解像オリジナルをGIMPで縮小した方がマシな気がするのは気のせいでしょうか？ｗ



◎単色画像への差し替え実験

遅延原因は判明しましたが、単純に画像解像度だけの問題か気になったので、単色画像への差し替え実験を行いました。



2048×2048の単色画像に差し替えたら、遅延現象発生しました。つまり、ファイルサイズや模様の複雑さは関係ない、ということです。（ちなみに、元のファイルは1〜2MB、単色画像は20KBです）



◎まとめ

今回分かったことを順にまとめていきましょう。

・画面に表示するテクスチャの種類が一定数を超えると
　急激に遅延する
　→一定数以下だとfpsは低下しない（「４枚」は偶然）

・画像１枚あたりの解像度が大きいと、負荷要因が高い
　→表示するのはその一部だけでも、
　　全体解像度分の負荷がかかる（ポイント）
　→ファイルサイズや模様の複雑さは関係ない

ここまでは理解できますね。


１ピクセル１バイトと仮定すると、

2048×2048＝4MB（画像１枚当たりのデータ量）
4MB×４枚＝16MB（画像４枚当たりのデータ量）

私のPCでは、描画テクスチャ量が16MBを超えると、CPUメモリからGDCメモリへの切り替え遅延が発生する、と考えると納得できます。（地形とか他の要素は省略）


この仮定を、旧方式に当てはめるとどうでしょうか？

256×256＝64KB（画像１枚当たりのデータ量）
16MB÷64KB＝256枚（切り替え無しで描画できる枚数）

この計算だと、描画テクスチャが256枚以下なら遅延しないことになります。

テクスチャ総数は数千枚に及んだものの、同時に描画するのは通常256枚以下だったので、遅延が発生しなかった…と考えると納得できます。

ふーむ、こういうことだったのか…。



◎今後の方針

遅延原因は判明しましたが、こうなると旧方式に戻すべきか悩みますね。今後の方向性によって変わると思いますが、

Ａ：切り替え遅延が発生しない方向を目指す
Ｂ：高速な切り替えを目指す
Ｃ：両方目指す

ＡかＣなら旧方式、Ｂなら前回方式にすべきかと思います。


Ａが実現できた場合、通常はＢよりも早そうですが、画面内のテクスチャ数が一定数を超えると急激に遅くなります。そういったことが滅多に無いよう工夫する必要がありますが、そこそこ実現できそうな気がします。

もちろん、ユニットの種類を増やすと上限256枚ではパンクしそうですが、解像度を下げれば許容枚数が増えます。既に80×80まで下げてますし、限界ギリギリの64×64まで下げると4096枚までOKということになります。

地形や簡易モデルのテクスチャ数も影響しそうなので一概には言えませんが、画面内のテクスチャ数を4096枚以下に抑えるのは、それほど困難ではないかもしれません。
（仮に超えたとしても、私のPCよりGDC性能が良ければ遅延しないかもｗ）


一方、Ｂが実現できた場合、テクスチャ数など気にせず無制限に追加できます。ただ、前回は30→7fpsまで低下したほどの遅延現象を、インスタンシングでどこまで回復できるか疑問です。（やってみないとわからない）


理想としてはＣかもしれませんが、今の私のレベルではハードルが高そうですし、開発やテストのコストも非常に高くなりそうです。（例えば、ＡＢ両実装プログラムでＡのテストパターンを考えたり準備するだけでも手間がかかりそうです）

進捗が非常に悪いので、これ以上進捗が遅れる要因は避けるべきでしょう。


というわけで、ＡＢどちらかにするつもりです。まだＢの実現性がわからないので、インスタンシング導入の様子を見て決めたいと思います。



◎次回予告

２月になったので、次回は「１月の総括と２月の目標」です。

テーマ : ゲーム製作　関連 - ジャンル : ゲーム

開発中のメイン画面
槍兵以外の画像を前回方式に置き換えた。画面内の画像数が一定量を超えると大幅に遅延するようだ。

---

◎連画の統合

今回は既存オブジェクトの画像を統合し、前回方式で実装します。

まずは連画取得ツールに画像統合機能を組み込みます。実はまだやってなかったのですが（汗）、組み込み前提でプログラム作成済なので、問題なく組み込めました。

連画取得から統合画像まで一発で出力できるようになったので、とても快適です。順次出力しましょう。



槍兵歩行ループモーションを出力したら、こんな感じになりました。無駄な隙間が多くて勿体ない気がしますね。

歩行モーションだけ解像度を上げて隙間を減らすことも可能ですが、モーションによって解像度が変わると見た目に違和感が生じるので、このまま採用します。

しかしそう考えると、最も連画数が多いモーションに解像度を合わせる必要がありますね。槍騎兵も隙間が多いのですが、とりあえず槍兵の解像度に合わせました。木の解像度は高めにしました。



◎実装

画像が準備出来たので、前回方式で実装しました。

　　　

槍騎兵や槍兵歩行モーションなどは問題なく実装できました。パフォーマンスは以前と同等です。

問題は木です。映像的には問題無さそうですが、これが視界に入るとパフォーマンスが大幅に低下します（30→5fps）。基盤クラスは兵士と共通なのに、何故木だけこのような状態になるのでしょうか？



◎原因調査

いろいろ試していたら、ちょっと不可解な現象を確認しました。

　　　

左から右にわずかにスクロールしただけで、40→7fpsまで低下しました。木の種類や本数を変えたりして似たようなパターンが発生しないか試したら、問題点が徐々に浮き彫りになってきました。

木の登録本数が増えるとパフォーマンスが低下しますが、これは以前と全く同じレベルでした。これは画面に表示された本数とは無関係で、ゲーム全体の登録本数に影響します。（400本（＆その他モデル）で30fps程度）

問題は、画面上に木が５種類以上表示されると、パフォーマンスが一気に低下する、ということです。

この「テクスチャ数が４以下だと早い」というのは心当たりがあります。昔書いた記事を読み返すと…あれ？この時は「キャッシュ」と結論付けてますね。う〜ん…。

でも、「４以下は早い」というのは過去に度々経験したので、ちょっと引っ掛かります。試しに、木の本数を以前と同数に戻して、木の種類を7→4に変更してみました。



以前と同じ30fosに戻りました！やはり４という数字がポイントなのかな？（不明）

ちなみに、画面内の本数が20本でも60本でも、ズームアップして拡大してもfpsは殆ど変わりません。



◎テクスチャ切り替え遅延

ところが、木を４種類以下に抑えても、移動ユニットを表示すると遅延現象が発生しました。



ユニット／モデル／テクスチャの関係は以下の通りです。

槍兵　：板ポリＡ：３モーション（３画像）
槍騎兵：板ポリＡ：１モーション（１画像）
木　　：板ポリＢ：４種類（４画像）

画面内に表示されているユニット
・槍兵と槍騎兵のみ：遅延現象なし
・木と槍騎兵のみ：遅延現象なし
・木と槍兵のみ：遅延現象発生
・木と槍騎兵と槍兵：遅延現象発生

槍兵のモーションを切り替えると、切り替え中に遅延が発生し、切り替えが終わって１モーションになると遅延しなくなります。

どうやら、カスタムBasicEffectで画面内に描画するテクスチャの総数が４〜５あたりが境目のようです。（モデルは無関係？）


一つ腑に落ちないのは「以前のテクスチャ差し替え方式は遅延しなかった」ということです。もしや、無意識のうちにマテリアルバッチを適用していたのでは？

…と思って以前のソースを確認したのですが、ModelMesh.Drawで普通に表示してるだけでした。以前のソースにマテリアルバッチを適用したら早くなるのかなぁ？（謎）



◎エフェクト情報の中身

以前と今回のソースを比較して、１つ気付いたことがあります。

以前のソースでは、Content.Load時に、各ModelMeshPart.Effectに固有のエフェクト情報を所持している。
今回のソースでは、Content.Load時に、（２回目以降も）同じエフェクト情報（アドレス）を示している。

ということです。読みだしたエフェクト情報を格納するフィールドはインスタンス毎に保持しているのですが、中身が同じアドレスだと意味無いですねｗ



◎エフェクト情報の複製

エフェクトファイルのLoad時に複製すべく、カスタムコンテントマネージャで呼び出したら、OutOfMemoryで落ちました。

カスタムコンテントマネージャって、メモリ効率悪いのかなぁ…いやそれ以前に、エフェクトファイルを何百回も呼び出す方が無謀か？（爆）

とりあえずエフェクトを複製したくて
Effect ef = content.Load("MyBasicEffect");
myEffect = ef.Clone(this.unit.GetGraphicsDevice());
としたら、エラーにはなりませんが、何も表示されなくなりました。そこでdraw()内に
myEffect.CommitChanges();
を追加したら、木と槍騎兵がそれぞれ１つだけ表示されました。どうやら、２回目以降に読み込んだエフェクトを.Cloneでコピーしても、無視されるようですね。



◎テクスチャ切り替えのタイミング

というわけで、テクスチャ１〜４枚につき１つのエフェクトファイルを用意するよう改修しました。中身の値は全部一緒なので無駄な気がしますが、クローンを何百個もコピーするよりはマシなので、当面は良しとします。

しかし、実際に動かしてみると、遅延現象が発生しました。Draw()内で毎回テクスチャ切り替えすると遅くなるようなので、初期設定とモーション変更時のみテクスチャを切り替えるようにします。



遅延現象は発生しなくなりましたが、木が２種類になってしまいました。これは、１〜４番の木と５〜７番の木でエフェクトファイルを共有させたためです。

そこで、エフェクトファイルを７個別々に用意したら、５種類目から遅延現象が発生しました。



◎モデル情報の中身

改めて考えると、木の板ポリモデルは７種類共通で、Content.Loadで読み込んだ板ポリインスタンスも全部同じ情報（アドレス）を示しているわけです。ということは、各板ポリインスタンスに個別のエフェクト情報を渡しても、最後に設定したエフェクト以外は無効ってことじゃないですか？

試しに、Draw()内の
ModelMeshPart.Effect = myEffect[〜]
をコメント化したら、木が１種類だけ表示されました。



木は20本あるはずですが、他の６種類が表示されません。やはり、最後に設定したエフェクト以外は無効なんですね。



◎結果

１テクスチャにつき１モデル１エフェクト用意して実装したら、「◎テクスチャ切り替え遅延」と同じ状態になりました。

ガーン！！

結局、「◎エフェクト情報の中身」以降は見当違いで無意味だったようです…（＞＿＜）



◎次回予告

遅延現象はモデルインスタンシングで解消できるかもしれないし、いざとなったら元の方式に戻せば良いので、どうにもならないという状態ではありませんが、遅延原因不明のままインスタンシングを適用して良いのか迷ってます。

・遅延原因調査の続き
・モデルインスタンシングの下調べ
・いきなりマテリアルバッチ適用

次回は上記の三択で考えています。さてどれになるやら？ｗ

テーマ : ゲーム製作　関連 - ジャンル : ゲーム

開発中のメイン画面
UVアニメの実装方式を変更して、前々回のパフォーマンスレベルまで回復させた。

---

◎シェーダー改修

今回はシェーダーを改修して、以前の速度に戻るか試してみます。

まず、メタセコイアで板ポリのUV設定を画像１枚分に調整します。


次に、BasicEffectカスタマイズサンプルにアニメテクスチャ左上座標計算を追加し、座標をBasicEffect.fxに渡します。
Vector2 TexCoord1 = new Vector2(tx1, ty1);
myEffect.Parameters["TexCoord1"].SetValue(TexCoord1);

最後に、BasicEffect.fxのテクスチャ座標設定を書き換えます。
// vout.TexCoord = vin.TexCoord;
vout.TexCoord = vin.TexCoord + TexCoord1;



動きました！
見た目は以前のサンプルと全く一緒ですが、今回はModelMesh.Drawによる表示ですので、頂点バッファやインデックスバッファが使用されて前回の方式よりも早くなった（以前のパフォーマンスに戻った）はずです。



◎パフォーマンス計測

前回の表示方式と今回の表示方式で、パフォーマンスがどの程度違うか計測しました。

　　　
板ポリアニメ100枚（左図）、同1000枚（右図）

　　　　　　 前回方式 → 今回方式
板ポリアニメ 100枚：60 → 60(fps)
板ポリアニメ1000枚：59 → 59(fps)
板ポリアニメ1500枚：30 → 40(fps)
板ポリアニメ2000枚：30 → 30(fps)
板ポリアニメ3000枚：20 → 20(fps)
板ポリアニメ5000枚：12 → 15(fps)

1500枚と5000枚以外のfpsは一緒でした。
エーッ！？何で？理解できない…（＞＿＜）

前回方式もバッファは使用されていたということでしょうか？
それとも、両方式共にバッファは使用されていないということでしょうか？

1500枚の時だけ10fps差が出る理由もよくわかりません。
プログラムや計測方法がどこか間違っているのでしょうか？



◎実装

この様子だと、実装してもパフォーマンスは変わらないかもしれませんが、一応試してみます。



前々回まで：20fps
前回方式実装後：12fps
今回方式実装後：20fps

前回の方式よりも早くなった…というか、以前のパフォーマンスに戻りました。

最初の予想通りの結果になったわけですが、逆にパフォーマンス計測テストの結果と合わないような気がします。前回方式は1500枚の時に10fps低下しているので、それと似たような現象が発生してたのかなぁ？



◎サンプルプロジェクト

今回の方式をHPにまとめてUPしました。

XNA3.1でUVアニメーション（シェーダー改修方式）

メインプログラムはわりとシンプルですし、少なくとも前回方式よりは早いので、こちらの方をお勧めします。



◎次回予告

今回の目標（以前のパフォーマンスに戻す）は達成したものの、いまいち釈然としませんね。

パフォーマンス向上への道を踏み外していない自信はありますが、パフォーマンス計測の自信はちょっと揺らいできました。今後モデルインスタンシング適用時は計測が重要なんだけどなぁ…。

とりあえず次回は槍兵以外の既存オブジェクト画像を統合し、今回と同じ方式にします。

テーマ : ゲーム製作　関連 - ジャンル : ゲーム