落ちモノパズル 私がアホミスをしなくなる日は来るのでしょうか？

あいさつ

どうも、はかせです。
今回は前回の続きの解決編です。
前回の続きになるのでまだ読んでいない人は読んでから
この記事を読むことを勧めます。
前回↓
hakase0274.hatenablog.com

またもや誤認逮捕をしかけました

前回ピースを大量に置いたらFPSが悲しいことになりました。
ピースがあるときとないときでは差があるのは描画処理です。
(まだ毎フレーム動く処理は描画処理しかないため)

なんで描画処理が重いと判断し
描画処理の軽量化を色々調べていました。

ただまずは描画処理のどこが重いのかを調べるため
処理時間を計ってみました。
処理時間を図ったコード↓

FuctionCountTimer::FuctionCountTimer()
{
	start = std::chrono::system_clock::now();
}


FuctionCountTimer::~FuctionCountTimer()
{
	auto end = std::chrono::system_clock::now();
	double elapsed = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
	std::wstringstream ws;
	ws << elapsed << std::endl;
	OutputDebugString(ws.str().c_str());
}

図りたいタイミングでインスタンスを作り
終わりたいタイミングでインスタンスを破棄します。
すると処理時間が出力窓に出るという単純なものです。
今回は描画パイプライン構築から描画完了までを図ってみました。

それで結果がこちらです。
(単位はmsです)

ん・・・？
16ぐらいだな・・・
これで20FPSはおかしいな・・・
ということでパイプラインは犯人ではなさそうです。

となると他のオブジェクトの更新かと思いましたが
さっきしれっと書いたようにまだ描画処理以外は更新処理がありません。

真犯人

勘の鋭い方ならもうなんとなくわかったかもしれませんね。

私は今回描画パイプラインの処理時間を計測しました。
それで処理はまだ描画処理しかつけていないとも言いました。
パイプラインは犯人ではないとも言いました。

細かいバックグラウンドは省くとして(主に私の勉強のためです)
描画処理に
今現在描画されているスクリーン座標をログとして表示させる機能
があったのです。

ある程度プログラミングをやったことがある人ならわかると思いますが、
ログ出力とかって結構性能の足を引っ張ります。
そんなものを描画処理をキックする度にやってたらそりゃFPSも落ちますよねｗ

ちなみにこの機能マクロ使ってDEBUG時以外は機能しないようになってました。
だからリリースビルドするとFPSが回復したわけですね。

あとがき

今回はまたもや私の誤認逮捕のお話でした。
前回で手痛い目にあったというのにまだ誤認逮捕をしてしまうとは
デバッガー失格です(´;ω;｀)

それにしてもログ機能を付けていたとは・・・
ん？じゃあ前回FPSが綱渡りになっていたのって・・・・・・？
ぁ…(´・д・`*)　ぁ(´・д:;.:... (´・:;....::;.:. :::;..

それでは今回はこの辺でノシ