プログラマ専用SNS ミクプラ

＞＞管理人さん
「４４章について」の投稿は、私が誤ってkaiさんの名前と重複してしまったものなので削除していただけるとありがたいです。

44章では各関数毎に処理速度を測定できるようにしていますが、
graph_main()でもし処理が重い場合、どの部分を見直すべきなのでしょうか。
また("最初")というのもありますがこれはどのような処理速度を測定しているのですか？
自分のは("最初")の処理だけで16～17ms←（すみません、単位がわからないですが）
という大きな値になってしまうのですが、これも処理の軽減の解決策はあるのでしょうか？

＞ 自分のは("最初")の処理だけで16～17msという大きな値になってしまうのですが

　44章の説明文に書いてある通り ScreenFlip()の中で垂直同期待ち
（裏画面にある絵を表にするのに最適なタイミングになるのを待っている）を
しているのでその時間が含まれています。

　つまりここで最終的なフレームレートを整える為の処理が
入っているとも言えますので、龍神録の性質上そこはあまり気にする必要は
ないかと思います。


　試しに WinMain関数の ScreenFilp()の下のところに
[color=#d0d0ff" face="monospace]
enter_func_tm("ScreenFlip");
[/color]
としてみて下さい。

　“最初”の時間の大半が “ScreenFlip”の方に移っているはずです。


　どうしても、ScreenFlip()を軽くしたいのであれば、
[color=#d0d0ff" face="monospace]
SetWaitVSyncFlag(FALSE);
[/color]
を DxLib_Init()の後にでもいれれば、ScreenFlip()での垂直同期待ちを
しなくなるので、ScreenFlip()の処理そのものは軽くなりますが、
今度は fps_wait()に時間がかかるようになります。

　これは fps_wait()でフレームレート（fps）をできるだけ一定に保とうと
（内部でウエイトを入れている）しているので、１フレームの処理が
早く終わってしまい空き時間が多くなればなるほどここが大きな値となります。

　最終的にこの状態から fps_wait()の処理をコメントアウトすれば
ほぼ最速でうごくようになるはずです。
　ただ代わりに fpsは不定となるので、それに合わせたゲームの設計が必要になります。

返信ありがとうございます。
SetWaitVSyncFlag(FALSE);
でたしかに処理速度は上がりましたが、描画ががたがたした状態になってしまったので
もうひとつのgraph_main()の処理落ちにあたってみようとおもうのです。
graph_main()では、画像のx座標や角度を出す計算式によって処理落ちするのでしょうか
それとも画像そのもの（量的に？）問題があるのでしょうか

＞ graph_main()では、画像のx座標や角度を出す計算式によって処理落ちするのでしょうか
＞ それとも画像そのもの（量的に？）問題があるのでしょうか

　難しいところです。
　graph_main()の中をみると判りますが、多数の関数を呼び出しを行っているので、
その中のどれに時間がかかっているのかを割り出す必要があります。

　graph_main()の中ではＤＸライブラリ関数の中を除けば、ほとんど座標や角度を
求めたりはしていません（グラフィックスを扱う名を持つ関数の中ですることではないですしね）。
　疑わしいところといえば、ループの処理回数と、その中で行われている画像の描画処理でしょう。

　まずは、graph_main()の中のどこに時間がかかっているのかを調べ、一番負荷の高いところから順に
その中のループ回数・描画回数を減らす、素材のサイズを小さくする、描画面積を減らす、などを
試みてみるといいのではないでしょうか。


　ところで、そんなことをしなければならないほど、サンタクロースさんの環境では
処理が一杯一杯なのでしょうか？

すみません、伝えるのを忘れていました。
というよりはこの掲示板に投稿してよかったのかもわからないのですが、自分は一応ＰＳＰで作っています。
そのせいでボス弾幕「サイレントセレナ」ではgraph_main()が30～40msまであがります。
おそらくは弾の描画関数に問題があると思います。
そこで初歩的な質問ですが
first_ini()で弾の計算を配列を用いてあらかじめしておいてボスのショットの計算の時に値を代入するように
したいのですが、値を保持したままボスショット計算の関数に渡せばいいのかわかりません。
どうすればよいでしょうか

＞名前の重複

今までにこれだけの種類の名前が使われたので
http://www.play21.jp/board/ranking.cgi?id=dixq
適当につけても被って不思議はないと思います＾＾；
ですのでお気になさらず。
完全にユニークな名前を付けたいなら、リンク先の画面で検索して
その名前がないことを確認するとよいと思います。

で、処理に時間がかかるのは、私の勝手な想像ですが、軌道計算ではなく、描画そのものではないでしょうか？
弾幕を描画するとき、かなり大量な描画が行われます。
PSPの性能がどれ位か知りませんが、ちょっと前の古いPCだと思えば、処理落ちしている原因は描画ではないかと（ただPSPの場合昔のPCより描画に特化しているはずなので、わかりませんが）
一度描画関数graph_mainを呼ばなかったときどれ位になるか試してみたらわかるのではないでしょうか？

で、配列の件ですが、軌道計算がボトルネックになっていないのなら意味がないです。

やはり、それより描画を工夫された方がよいかと。
PSP系の話は最近ホットなようなので、他の方がどのような工夫されているか調べてみてはいかがでしょう。
出来るだけアルファブレンドしないとか、FALSE指定で描画出来るところはするとか・・。
あと、DXライブラリではないですが、SDLというライブラリでは、アルファブレンド値を128にすると
他のブレンド値よりも描画がとても速くなるという性質があります。
（つまり127とか指定する位なら128にしろということ）
DXライブラリにもそういう高速化出来る何かがあるかもしれませんね。
詳しい話は製作者様にお聞きになるといいと思います。

なお、msというのはミリ秒です。1000ミリ秒=１秒です。
１フレーム辺りの時間が16ms～17msとなる理由は1秒を60フレームで割ってみるとわかりますね。

>>サンタクロース様

おそらくサンタクロース様はDXライブラリPortableを使用していると思いますが
それならば、本家のBBSで描画についての高速化が詳しく書いてあるので参考にしてみてはいかがでしょうか

http://dxlibp.sourceforge.jp/


>> 管理人様
>>DXライブラリにもそういう高速化出来る何かがあるかもしれませんね。

SetDrawBright関数ですが、以前にこんなことが書かれていました。

http://hpcgi2.nifty.com/natupaji/bbs/pa ... ew&no=1309

わけのわからない事態に陥りました。
graph.cpp内で内容を変更することはおろか、空白の部分をスペースキー一回押すだけでも
graph_back,board,fps,check_time,develop
以外の全ての画像が描画されなくなってしまいます。
画像は全てパレット形式に統一してあります。
スペースキーですらこうなるので、原因がさっぱりわからないです