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

Arkroyal
記事: 80
登録日時: 2021年1月06日(水) 10:41

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

投稿記事 by Arkroyal »

くろうど様、ご指導ありがとうございます。

BattleManager._statusWindow.refresh()はダメージ処理の並列コモンのみで使われており、その部分を削除してみたところフレームの変動はありませんでした。
アバター
WTR
記事: 625
登録日時: 2015年12月22日(火) 19:14

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

投稿記事 by WTR »

結局原因はわかっていないのですけど
定常的にFPSが落ちるということは並列処理か止まらずにループしてるコモン①なのでしょう。
複合要因かもしれませんが。

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

関係なさそうなゲージの更新も一応止めてみた方がいいと思います。
Twitter、はじめました。
https://twitter.com/wtr_in_reverie/
Arkroyal
記事: 80
登録日時: 2021年1月06日(水) 10:41

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

投稿記事 by Arkroyal »

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

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

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

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

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

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

ご指導してくださったWTR様、くろうど様、jp_asty様!誠にありがとうございます!!
アバター
くろうど
記事: 318
登録日時: 2016年1月22日(金) 20:52
お住まい: 東京都
連絡する:

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

投稿記事 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回数が少なければ、上記の内容は関係ないと思われます。
よろしくお願いします。
▼だいたいTwitterにいます。たぶん。
https://twitter.com/kuroudo119
Arkroyal
記事: 80
登録日時: 2021年1月06日(水) 10:41

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

投稿記事 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くらい追加で落ちるのを確認しました。

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

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

“MV:質問”に戻る