0_0_57

 obake   specification   version 

0_0_57 以降、盤面から消したお化けを補充するロジックを組み込んでいる

オブジェクトを破壊した時に、盤面上の位置も記録させることはできるが、盤面を回転させることができたりするので、位置を記録してもたぶん意味無い。記録した位置にお化けが居なくなっている可能性高いから。

つまり

DoronFlg = true;

DoronFlg が有効化された刹那で盤面を総当り検索、その時点で空きスペースへお化けを発生させるのが無難と考えた。

発生したお化けはテレポートで出現する仕様で作ってみることにした。一般的な落ち物パズルだと上から落下して補充されるが、テンプレ的な表現だし少しアレンジして出現はエフェクト付きテレポートで作ってみたいと思ったから。

出現するタイミングはユーザ定義関数 QF_Dororon で条件判定している。

///QF_Dororon
if (DoronFlg){
if (!Phy_Falling){
if (!MvBricksPaiRFlag){
if (TryCombTimer == 0){

show_message(CtCaptuN);

/* finalize */
DoronFlg = false;
CtCaptuN = 0;
   };
  };
 };
};

bitwize 使ったフラグにすれば if 条件判断は一つにまとめられると思うが、既存の変数を利用したほうがコードの見通しは良いので、たぶんこのまま使うと思う。デバッグが増えることは避けたい。

メモ

ユーザ定義関数 Phy_End を修正。条件判定に無駄があったためそこを直した。重力関係で今後問題が発生した場合はこの関数に加えた変更にも注意。

バグ発見

バグ発見 → _55D_fatal_error.gif

version 0.57 編集中に発見。新しいものではなく 0.55 以前から存在したバグの可能性があったため、0.55D へ遡った結果、再現できた。

オブジェクトを選択中に、選択したオブジェクトより下段で 3-Match 判定があったとき、現在選択中のオブジェクトは選択を強制解除される。この際にバグがあり、選択していたオブジェクトの情報が間違った情報で上書きされる。

具体的には カラー情報（ TiD ） が -4 判定となっている。Object ID には間違いがなかった。

考え方としては

  1. 選択している
  2. 3-Match 判定が選択より下で発生（ つまり重力落下中 ）
  3. 重力処理、もしくは選択解除 = PickTiID に絡んだ処理

だとすると Phy_Ck_Chain 辺りが怪しい？

それとも、重力が機能した時点で選択を解除する処理だから、Phy_Control 関数？

Phy_Start = false;
    if (n == true){
        Phy_Falling      = true;
        MvBricksPaiRFlag = true;
        var j            = PickTiID;
            if (instance_exists(j) == true){
                if (j.DownWell == true){
                    PickTiID  = noone;
                    PickTileF = false;
                    Clear_PickedAround();
                };
            };
    };

PicktTID == noone; の辺りで処理を確認したが、選択中のオブジェクト ID ではなく、その一個前に選択したオブジェクト ID が履歴に残っていて、その履歴を元に TiD = TiDBak; 的処理をしているため TiD == noone; になっているような？

結局良く分からなかったため、ソースコードを検索しまくってひとつミスのある関数を探し当てた。mv_SwapBackColor 関数。

    if (instance_exists(a) == true){
        if (a.TiDID = 1){
            a.TiD    = a.TiDBak;
            a.TiDBak = noone;
            a.TiDID  = 2;

ここがおかしかった。→ if (a.TiDID = 1)

なぜ TiDID に数値を代入してる……正しくは

if (a.TiDID == 1)

しかしバグ自体は直らなかった。あとは怪しいところが限られているため

QF_SwapColor これしかない。

呼び出し元は QF_IF_PRESSed なので、こちらの判定条件を修正する方が先か？

QF_IF_PRESSed は処理が複雑。コードが読み取りにくいためミスもありそう。QF_IF_PRESSed が条件判断に誤爆を含んでいるのだと思われる。しかし複雑な割に案外鉄板な処理になっているため、ここにバグの温床は見つからなかった。

もう一個あった

TAFlag の処理を追っていたらもうひとつ怪しいものが見つかった。PK_Set_WTimer 関数。この関数呼び出しは Phy_Control 関数から、しかもこの時に TiD と TiDBak を反転処理してる部分もある。

オブジェクトは最初に選択された時点で TAFlag = true; となる。だから PK_Set_WTimer 関数が機能したときに、選択されているオブジェクトの場合、TiD と TiDBak が反転されてしまう可能性はある？コードを検討した結果、その可能性は無かった。

しかし本来 TAFlag が false だった場合は TiDBak と TiD は値を交換されるので、ここは本来 PickTiID と一致するオブジェクトを処理する場合には、TAFlag が false の時と同じ処理をしなければいけないのかもしれない。

発動タイミングは実にシビア

デバッグを重ねていくと分かったが、発動のタイミングはタッチ検出のタイミング次第で結果が変わる。タッチのタイミングが速すぎるとバグが出ない。ギリギリのタイミングまで待たないとバグが発生しないからこれまで見つからなかったのだと思う。

最終的に今回のバグ原因は PK_Set_WTimer 関数と Phy_Control 関数、この二つに絞れた。そして問題になっているフラグは TAFlag == true;の時の処理である。

決着

PK_Set_WTimer 関数に処理を追加することでバグを回避できるようになった。

    if (TAFlag == true){
        if (a == ev.PickTiID){
            TiDBak = TiD;
            TiD    = noone;
        }
        else{
            //show_message("This is the Physics Canseller Flag and Done");
            AddVspeeD = true;// to Physics Canseller
        }; 
    }
    else{
        TAFlag = true;
        TiDBak = TiD;
        TiD    = noone;
    };

動作に問題が無いことを確認後、マイナーバージョンアップして新機能の実装へ戻る。




次へ

前へ