処理落ちの軽減についてと、発射に時間差のある弾の描画順位について

[サンタクロース]

こんばんわ。サンタクロースです。
自分は今PSPで東方の移植のようなものを作っているのですが、正直処理落ちに悩まされるのです。
そこで、思い切ってint→shortに置き換えてしまおうと考えているのですがどうなのでしょうか？
処理落ちの軽減は期待できるのでしょうか？
かなり、大規模な作業なので一度聞いておきたいと思います。

それともうひとつ質問です。
以前弾の描画順序を変えるにはどうすればいいかという質問がありましたが、
それは、発射される時間が違っても可能なのでしょうか？
例えば、先に撃たれた弾が後に打たれた弾に追い越され、
後に打たれる球が下に描画されるようにしたいのです。

[softya]

>そこで、思い切ってint→shortに置き換えてしまおうと考えているのですがどうなのでしょうか？
整数演算を変えても効果がない可能性が大きいです。構造体がコンパクトになるので多少はメモリアクセスは減りますが32768でオーバーフローするので、よほど気を付けないとバグだらけになります。
前のスレの時にも話題になっていますが、とりあえずテストプログラムで実測しましょう。
私が負荷だと思うのは、float→int、int→float変換です。多発していませんか？元の龍神録のプログラムだと大して気にしていないでプログラムしてると思います（パソコンの方が能力が高いので）。
とにかく処理落ちの原因を調べて、テストで間違いない事を確認し、実際に直すって工程を繰返さないとダメです。これもプログラマのデバッグの作業の一環ですよ。


>後に打たれる球が下に描画されるようにしたいのです。
それこそ弾が発射される度にソートするしか無いですね。
あるいは大きさで分けたリスト構造にするとか。今の龍神録の配列構造は捨てないといけないのと、リスト構造にすることで負荷が増えるのが問題ですが、ソートの負荷とどちらが良いかですね。

[たかぎ]

> そこで、思い切ってint→shortに置き換えてしまおうと考えているのですがどうなのでしょうか？

どの部分を変更するのかにもよりますが、一般的にはintよりshortのほうが遅くなります。
PSPはMIPSなので、変数を評価する際の汎整数昇格は問題にはなりませんが、int型の演算結果をshort型にする際に、シフト演算が2回余計に必要になります。
ただし、int型の大きな配列をshort型の配列にするのであれば、キャッシュのヒット率を上げられますし、キャッシュラインに収まる可能性も上げられますので、結果的に速度を向上させられる可能性はあります。また、MIPSのアーキテクチャやABIでは、32Kバイト以上の配列を使ったり、関数に5個以上（浮動小数点数の場合は3個以上）の仮引数を持たせたりすると、効率が非常に悪くなります。
ソースを見れば、ある程度小手先で改善できる点は見いだせるかと思いますので、そこを直した上で、あとは実測でしょうね。

> それは、発射される時間が違っても可能なのでしょうか？

可能かどうかが知りたいのであれば、可能です。

[ft]

こんにちは。
サンタクロースさんと同じくDXPで東方PSP劣化移植を試みている者です。
（ちなみにDXP掲示板では「zane」と名乗っています。掲示板毎に適当に押したキーをネームにしてますｗ）

本題ですが、処理落ちしてしまうということで、どのくらいの弾幕でどれだけ落ちてしまうのでしょうか？
DXPは安定性を重視して出来る限り高速に描画するように設計されているようで、やはり限界もあると思います。

[少年X]

こんにちは
僕もPSPで東方を移植しようとしているものです。

処理落ちが問題なら、やはりsin,cosのテーブル化をお勧めします。ftさんに指摘されて直してみたところ、すごく高速になりましたよ。でも、大幅なプログラムの書き換えが必要になるので大変でした。
＊僕は初心者だからてこずっただけかも・・・

[Justy]

　概ね回答も出そろっているような気もしますが、（PSP持ってないのに）私からも少しだけ。
　
　もし、sizeof(double)!=sizeof(float)なら、int→shortよりも double→floatでしょう。
　前提条件が正しければ、計算途中も含めて全て floatにすることで結構大きく変わる可能性があります。

　sin/cosの方は VFPUに専用命令があったはずです。テーブルでもいいですが、これを使って計算しても
結構早くなるかと。

　最後にもし実はコード的に「東方の移植」ではなく「龍神録の移植」だったりするなら、
PSPのアーキテクチャ的に配列＋フラグによる有効無効判定あたりは一工夫（アルゴリズムを見直す、
プリフェッチするなど）しないと激しい D$ミスを引き起こしそうな気がする（気がするだけですので、
実際には測定が必要ですが）ので、そのあたりも遅くなる要因になっているかもしれません。

[サンタクロース]

こんばんわ。皆さん回答ありがとうございました。
よくよく考えてみたのですがやはりintからshortはすごくわかりにくいですね。
ひとまずsin,cosのテーブル？という意見を参考にしてみたいと思います
描画順位については二者択一なところがあって少し悩みます；
とりあえず処理軽減の出来次第で決めたいと思います

[ft]

以前Justyさんの仰るsin/cosのVFPU専用命令を使ったことがあるのですが、遅くなってしまった記憶があります。
でも確かテーブル以外のsinf/cosfとしていた箇所を全てVFPU命令にした場合の結果でしたので、
細かく見て使い分けすればもしかしたら変わるかもしれません。。。

[softya]

サンタクロースさんへ。
実測や問題点の洗い出しをせずに、とりあえず高速化に有効な手を打ってみると言うのは問題の解決を遅らせるだけですよ。

高速化は、
１．色々なポイントの速度を実測
２．問題点の絞り込み
３．問題点をテストプログラムで実測
４．テストプログラムで改良手段をテスト
５．改善されるまで３から４を繰り返す。
６．本物に反映。
７．実際に高速化されているか、本物を実測でテスト。
と地道にやりましょう。