プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
画像解像度変更(GIMPで縮小02)
開発中のメイン画面
低解像画像に差し替えたら、遅延現象が解消された。木の画像はGIMPで縮小したものを使用している。



◎エフェクトの使い回し

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

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

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

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

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



◎ミップマップの有無

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

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

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

6 → 2 (fps)

さらに低下してしまいました(爆)



◎画像解像度の変更

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

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

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

画像解像度変更(40×40)   画像解像度変更(GIMPで縮小01)

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

やっと遅延原因が判明しましたよ~!!


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

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

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



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

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

単純画像に差し替え

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



◎まとめ

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

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

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

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


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

2048×2048=4MB(画像1枚当たりのデータ量)
4MB×4枚=16MB(画像4枚当たりのデータ量)

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


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

256×256=64KB(画像1枚当たりのデータ量)
16MB÷64KB=256枚(切り替え無しで描画できる枚数)

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

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

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



◎今後の方針

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

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

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


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

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

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


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


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

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


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



◎次回予告

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

スポンサーサイト

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

コメント

ちなみに

1ユニット1コマ分のテクスチャ、64×64が限界というのはどの辺の兼ね合いで?

こんにちは~

単純に、見た目の問題です。カメラのズームアップにそこそこ耐えられる解像度を事前にチェックしました。

エイジオブエンパイアのように、カメラの角度や距離を一定にするともっと下げられそうですが、できれば一人称視点を可としたいので、64×64が限界と考えています。

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。