ページ 22

Re: バトル中に使う自作QTEの最適化について

Posted: 2021年8月18日(水) 22:23
by Arkroyal
くろうど様、ご指導ありがとうございます。

BattleManager._statusWindow.refresh()はダメージ処理の並列コモンのみで使われており、その部分を削除してみたところフレームの変動はありませんでした。

Re: バトル中に使う自作QTEの最適化について

Posted: 2021年8月18日(水) 23:19
by WTR
結局原因はわかっていないのですけど
定常的にFPSが落ちるということは並列処理か止まらずにループしてるコモン①なのでしょう。
複合要因かもしれませんが。

1つ1つ止めて確認することはできるでしょうか。
もちろん止めることで意図しない動作…というか全く動作しなくなってしまうと思いますが
とりあえず原因がわからないことには対策を考えられないので。

関係なさそうなゲージの更新も一応止めてみた方がいいと思います。

Re: バトル中に使う自作QTEの最適化について

Posted: 2021年8月23日(月) 11:36
by Arkroyal
WTR さんが書きました:結局原因はわかっていないのですけど
定常的にFPSが落ちるということは並列処理か止まらずにループしてるコモン①なのでしょう。
複合要因かもしれませんが。

1つ1つ止めて確認することはできるでしょうか。
もちろん止めることで意図しない動作…というか全く動作しなくなってしまうと思いますが
とりあえず原因がわからないことには対策を考えられないので。

関係なさそうなゲージの更新も一応止めてみた方がいいと思います。

結局のところ、「多数のイメージを一瞬に出力するせいでフレームが落ちる」という結論に至りました。

Arrowlist作りをプラグインコマンドで実行するようにしたりゲージ関連の部分を消したりもしてみたところ、失敗するか成功するかに関係なくリストが更新されるときにフレームが必ず落ちたのでそれしか見当が付きませんね。

役に立つかはわかりませんが、万が一のためにArrowlistをイメージに出力する処理に当たってthis.wait(1)を入れました。

ご指導してくださったWTR様、くろうど様、jp_asty様!誠にありがとうございます!!

Re: バトル中に使う自作QTEの最適化について

Posted: 2021年8月24日(火) 12:33
by くろうど
こんにちは。
結局のところ、フレームが落ちる処理は特定できたけど、解決してない……という状況でよろしいでしょうか?

前回、私が言ったrefresh処理についてなのですが、
BattleManager._statusWindow.refresh() は
BattleManager.refreshStatus() の中で呼ばれており、
この処理はターン開始、終了、キャラクター行動時など何かある度に呼ばれています。

そのため、スクリプトで明示的に呼んでいる以外にも
裏で呼ばれている可能性があります。

このrefresh処理を辿っていくと、
Window_BattleStatus.prototype.refresh() が呼ばれていて、
その中の drawItem() で、
drawGaugeArea() も呼ばれています。
ゲージを表示する処理です。

その drawGaugeArea() をさらに辿ると、
Window_Base.prototype.textColor という処理があります。

一見なんてことない処理なのですが、
このtextColorは、色データを取得するために、
Window.png に毎回アクセスしているようなのです。

そのため、このtextColorは意外と重い処理となっています。
つまり、「ゲージ関連の部分」は重いと思われます。

というわけで、
スクリプトから呼んでいる以外に、裏で呼ばれている
Window_BattleStatus.prototype.refresh() の回数を
console.log 等で確認の上、
多いようであれば、
以下のプラグインで色データ取得回数を減らせるので、お試しください。

↓GitHub↓
https://raw.githubusercontent.com/kurou ... D_Color.js

尚、refresh回数が少なければ、上記の内容は関係ないと思われます。
よろしくお願いします。

Re: バトル中に使う自作QTEの最適化について

Posted: 2021年8月26日(木) 11:49
by Arkroyal
くろうど さんが書きました:こんにちは。
結局のところ、フレームが落ちる処理は特定できたけど、解決してない……という状況でよろしいでしょうか?

前回、私が言ったrefresh処理についてなのですが、
BattleManager._statusWindow.refresh() は
BattleManager.refreshStatus() の中で呼ばれており、
この処理はターン開始、終了、キャラクター行動時など何かある度に呼ばれています。

そのため、スクリプトで明示的に呼んでいる以外にも
裏で呼ばれている可能性があります。

このrefresh処理を辿っていくと、
Window_BattleStatus.prototype.refresh() が呼ばれていて、
その中の drawItem() で、
drawGaugeArea() も呼ばれています。
ゲージを表示する処理です。

その drawGaugeArea() をさらに辿ると、
Window_Base.prototype.textColor という処理があります。

一見なんてことない処理なのですが、
このtextColorは、色データを取得するために、
Window.png に毎回アクセスしているようなのです。

そのため、このtextColorは意外と重い処理となっています。
つまり、「ゲージ関連の部分」は重いと思われます。

というわけで、
スクリプトから呼んでいる以外に、裏で呼ばれている
Window_BattleStatus.prototype.refresh() の回数を
console.log 等で確認の上、
多いようであれば、
以下のプラグインで色データ取得回数を減らせるので、お試しください。

↓GitHub↓
https://raw.githubusercontent.com/kurou ... D_Color.js

尚、refresh回数が少なければ、上記の内容は関係ないと思われます。
よろしくお願いします。


ご指導ありがとうございます!!

フレームの件はリアルタイムにプレイヤーの入力を監視するところをイメージボタンで処理させることでどうにか解決できました。現在は57~60フレームを維持しています。

この状態でくろうど様のアドバイスが気になって試してみたところ、BattleManager._statusWindow.refresh()を呼んだ瞬間フレームが2~3くらい追加で落ちるのを確認しました。

なのでこの部分も別の処理方法を探してみて、バトルステータスのリフレッシュを使わなければならない場合はぜひくろうど様のご指導に従うことにいたします!

親切に教えてくださって誠にありがとうございます!!