0_0_50

 obake   specification   version 

_49 から引き続きバグ持ちだが原因が不明

_45YYC.exe で動作を確認したがやはり同じバグを抱えている。 現在は _49 に施した修正の結果がどれほど影響あるか確認中。

スクリーンショット

Bug 0_0_50_0B ScreenShot

動画で見る発生手順

  1. 連続スワップする
  2. 3-Match で連鎖確定させる
  3. 連鎖確定する直前操作で任意のタイル選択( 選択は不要 )
  4. するとスワップ中のタスクが中断される
  5. 連鎖確定されたタイルもスワップに失敗してる

なんとなくわかってきた

キューは先入れ先出しだから連続スワップした際に、かならず先のものが評価される。 しかし先に動かしたものは 3-Match が発生しなかったのであとは元の位置に戻るだけの処理

  • SwapColorQue
  • SwapReColorQue

上記二つのキューに入っていた ID になにか順番処理的な不具合がある

恐らく、先に入っていたキューが戻ってきてるときに後続のキューで連鎖が発生したため スワップ処理が中断されるような処理がどこかに紛れている

ここまで分かれば直せる気がしてきた

問題がありそうな箇所

クラッシュしなくなったのはありがたいが、具体的なエラー箇所がわからないため動作を観察して推測するしかない

プロファイラから追跡してもデータ構造部分が見えないので、所詮インタプリタとそれに付随するデバッガ程度の機能だ、特にシビアなタイミングで何が起こっているかを知りたいが、これだと役目を果たして貰えそうにない。期待しすぎだ。

  • TS_CK_Vanish();

この関数はすでに手を入れてある、しかしキューを扱っている部分なので一応今後もチェックは必要、例外が発生した時のキャッチフォローも入れておいた。

  • TS_Slide();

この関数が上流に当たる。TS_Ck_Chain(); を呼び出している関数で、TS_Ck_Chain は TS_CK_Vanish(); など一連の関数を呼び出ししている。

TS_CK_Chain は二回呼ばれている。これはスワップが必ず二つのタイルを対象とした操作だから

  • QF_Movement();

  • Chk_3Matches( id, loops );

  • mv_SwapBackColor();

  • mv_SwapReEnter();

  • mv_Action();

本命はこの 5 つか

使用しているキュー

  • SwapColorQue
  • SwapReColorQue
  • VanishList
  • PickTileQueA
  • PickTileQueB

mv_Action と QF_Movement と Chk_3Matches

この 3 つの関数を重点的に改修する必要がありそう

mv_Action → 色々と怪しい処理があったので直したが、あまり関係無さそう

動作一覧

  • QF_IF_PRESSed - - - ( MvTargetCT += 2; )

    • QF_SwapColor - - - ( ds_queue_enqueue(SwapColorQue, a,b); )
  • QF_Movement - - - ( if (MvTargetCT > 0) )

    • mv_Action
      • mv_A ~ F
        • Chk_3Matches
          • mv_SwapBackColor
          • TS_Ck_Chain
          • mv_SwapReEnter
          • mv_Exits
        • mv_Exits
    • TS_CK_Swap

直せた

  • QF_Movement

この処理を中心に

  • mv_Action

  • TS_CK_Swap

  • TS_CK_AddVanish

これら関数の内容を修正した

今回特に大きな修正は QF_Movement で、点検するとかなりいい加減な処理になっていた。これまで正常に動いていたのは正常に動いていたように見えただけで、実際はマルチスワップの動作 + 3-Match の判定処理はデタラメだった。

まず FIFO について、キューは head と tail しか無いので head と tail の中間に存在する値にはアクセスできない。

そしてマルチスワップの場合、最初にスワップした組みがかならず最初に 3-Match 判定される保証はないので、かならずしも順番通りに処理されるわけではない。あとからスワップした組みが 3-Match 判定を受けて消える場合を想定した作りになっていなければならなかった。しかしこれを考慮してない設計だったためバグの温床となっていた。



次へ

前へ