Conversation
| //カメラを待ってる状態なら | ||
| if (that.kag.stat.is_wait_camera == true) { | ||
| that.kag.stat.is_wait_camera = false; | ||
| if (flag_complete) return; |
There was a problem hiding this comment.
全ての処理は一回だけにしました。（wait=falseの場合、flag_completeを見ていないので複数回処理が発動してしまっていました）
| if (flag_complete) return; | ||
| flag_complete = true; | ||
| setTimeout(function () { | ||
| that.kag.stat.is_move_camera = false; |
There was a problem hiding this comment.
is_move_cameraをnextOrderの前にfalseにするように微調整しました
| } | ||
|
|
||
| that.kag.stat.is_move_camera = false; | ||
| }, 20); |
There was a problem hiding this comment.
300 -> 20。こちらの手元で実測する限り、概ね4ms以内に合計4つのcompleteイベントが飛んできているのを観測しています。
なお、completeイベントの最後の一つで発動するのが正しいと思いますが、 a3d の詳細な仕様がよくわからなかったのでそこまで深堀してません。（本質的にはa3dが複数回complete飛ばしてくるのがおかしいとは思います）
There was a problem hiding this comment.
テスト環境が足らずに確信ないのですが、低スペック端末だともしかしたら厳しいかも？という報告があって、ちょっと調査中です。やっぱり最後の1回のcompleteをもらうようにして、setTimeoutを外す方が健全かもしれません。
- アニメーション対象のレイヤーから
objis(":hidden")を除くようにa3d側または呼び出し側で判定を変える - completeイベントの数をカウントして、最後の一つでcomplete処理を実装するように変更する
アニメーションが終わっていない内にどこかのレイヤーのアニメーションが動かなくなると、判定に失敗するという副作用はあるので、本当はa3d側でアニメーションに想定の2倍時間がかかっていたらタイムアウト、みたいのもあるといいかもしれませんが。
| that.kag.stat.is_wait_camera = false; | ||
| if (flag_complete) return; | ||
| flag_complete = true; | ||
| setTimeout(function() { |
There was a problem hiding this comment.
reset_camera側、setTimeoutが設定されておらず、completeが複数回飛ぶ際にcssリセットが複数走る等の状態になっていたため、camera側と同じ構造にしました。
| } | ||
| } | ||
| } | ||
| }, 20); |
There was a problem hiding this comment.
このため、ここの20msが副作用として発生します。
1 participant
すみません、 #133 のがいい気がします。合わせてご確認いただけると助かります。
本PRについては、以下の説明並びにコードに対するコメントをご参照ください。
前提
cameraをwait=falseで利用した場合、連続で利用するとwait_cameraをかけても上手く動作しないことがある。
また、cameraをwait=trueで利用すると、動きが少しもっさりする。
解決する問題
副作用
reset_cameraに20ミリ秒waitを入れたため、reset_cameraでは逆に少しもっさりするようになる。
解決しない問題
cameraをwait="false"で起動し、その演出が終わらない内に違うcameraを起動する。
この場合、前のcameraのcompleteイベントで次のcameraが終了扱いされてしまう問題が残る。
このため、cameraの利用はwait=trueで利用するか、wait=falseで利用した後次のcamera演出の前に必ずwait_cameraを挟む、という制約をつける必要がある。本制約は本PRで解決せず、また文書にもない。
※本PR前の状態だとそもそもwait_cameraで待ちきれないので、この制約を守っても複数回のcamera演出の連続仕様をwait=falseで利用する事は難しい状態だったのが、本制約をつければ利用する事ができるようになった、ともいえる