続・偶発トラブル対処
前回記事↓の続報です。
問題が起きて困った困った、と言ったままほったらかしなのも不誠実なので、その後の経過をご報告したいと思います。
問題箇所は掴めたっぽい
あの後、どうにか切り分けしたいなと思い、無い知恵を絞りながらあれこれと考えた結果、「描画だけが固まる」 っていう現象が、よくあったらしいMVとは違ってMZでは他であまり聞かれないという現実にまず目を向けることにしました。
他にはない、つまり自分のプロジェクトにだけ入れているであろうもの…といえばまあプラグインですわね。
かつ、MVからMZで大きく変わった一つの点として処理落ちと描画の関係性があって、
- MV：処理落ちが起きると飛んだフレーム分、描画もスキップする
- MZ：処理落ちが起きると処理が遅れた分スローになって描画も同期される
例えばこの部分が先祖返りみたいなことを起こしていたら、MVでみられた一部の不具合も起こり得るよなと考えました。
該当部分のコアスクリプトはここですね。
rmmz_core.js
Graphics._onTick = function(deltaTime) {
this._fpsCounter.startTick();
if (this._tickHandler) {
this._tickHandler(deltaTime);
}
if (this._canRender()) {
this._app.render();
}
this._fpsCounter.endTick();
};
でこのGraphics._onTickをオーバーライドしてるのが、本作で「FPS調整」のオプション機能を司っているプラグインです。
機能としてはオプション値に従って描画を60FPS・30FPS・15FPSと可変にし、下げたレートでは描画のみを1/2、1/4にそれぞれスキップするというものですね。
これによって、ブルームやチルトシフトなどの画面エフェクト処理で描画エンジンに負荷がかかっていてもその頻度を落とすことでゲーム自体の処理遅れを防ぐことを期待できます。
で、その処理内容を改めて読み返しても、ロジックとしてはどうも間違っているようには思えなかったんですよね。ただ、コードをちゃかちゃか弄っていたところ、不具合報告にあったような現象に近いものを再現することはできたんです。
なので、半信半疑ながらここはひとつ思い切って、当該処理のオーバーライドを一切封じて機能を無効化したテストパッチを公開してみようと思い立ちました。
当たりなら当たり、外れならまた別の箇所を探すつもりで。
テストパッチのお知らせ【一部現象向け】｜Akari blast! (2023/7/13)
実験のようなものだと明言して、ダメ元でお祈りしたところ。
プレイヤー様のご報告により当たり判明。
大きな前進となりました。
じゃあどうする
って話です。一部現象向け任意パッチみたいなものだとしても未来永劫配り続けるわけにもいかない。ちゃんと正式なアップデートに組み込んで保守性も維持しないといけない。なにより現状ただ機能を潰しただけなので処理が重めの環境には厳しいソフトになってしまう。
ということで今度は該当箇所の改修に取り掛かります。
まず僕は前提としてそもそもノンプログラマーなので他人の書いたコードは基本的に雰囲気読みしかできません。なので改めてGraphics._onTickの仕組みをChatGPTに解説してもらうことにします。
Graphics._onTick関数が何をしているのか- プラグインでオーバーライドされたコードが何をしているのか
- その上で偶発的・環境依存で不具合が起こり得るのか、またその原因はなにか
という感じで、まずはロジックへの理解を深めたり不具合の原因を探ったり。まさに勉強…。
これによると、環境依存の部分はハードウェアの問題やWebGLの問題というのはあり得るという回答ではありました。逆にモニター・ディスプレイのリフレッシュレートやティアリングとの関連性は考えにくいとも。
そこから紆余曲折を経て、現在改修したテストコードが手元にあるという状況です。元のプラグインが持つ機能を維持しつつ、描画更新が停止している場合はそれを検出して強○描画が入るフェイルセーフやそもそものフレームカウント方法のロジックを変えてみたりなど盛り込まれており、これがうまくいけば正式アップデートへの適用も期待できます。
ただ元のプラグインから大きく書き換えてしまっているというのもあり、これはもう改修プラグインというより他の関数まで含めて新規プラグインとして組み上げてしまったほうが良いような気もしている…
ともかく準備が整い次第、また祈りの新テストパッチへ参る次第です。
頼むぞ…