Darkside(リンクエラー修正しました)

2013年11月22日(金) 21:39

悪戦苦闘

 大掛かりなプログラムが不具合無くすんなり動く確率は、ほぼゼロだ。
 まず考えねばならないのは、デバッグ方法である。

 ミサイルコマンド内部キャラの動きをシミュレートするとして、その最初に
memory.readbyte() してワークRAM → シミュレート用変数に取り込まねばならない。シミュレートはシミュレート用変数を書き換えて行なう。実際のワークRAMを書き換えたのでは、MAME の動きが変わってしまう。
 取り込んだらシミュレーションを行い、その結果として変化したシミュレート用変数をファイル出力する。続いて
MAME 自体を emu.frameadvance() して進行させ、ワークRAMの変化をファイル出力する。
 そして、両者を比較する。正確にシミュレートできていれば、ミサイルの位置や爆煙の状態など、同一の変化を示すはずだ。

 エクセル上で比較し易いようにファイル出力するデバッグ用ブログラムを作成しておく。

 途中でズレるのは想定していたが、僅か数フレーム以内でズレまくっている。まるでシミュレーションになっていない。
 爆煙の変化が数フレーム先でズレて、そうなるとスマートボムの動きなど全く一致しなくなる。未来予測が使い物にならない。天気予報どころではない酷さだ。デジタルなプログラムなのに、どうしてこうなった?

 爆煙がズレるのは、20個のワークを4個ずつ5エリアに分けて「今度処理するエリア」を管理している変数の内容がズレているからだ。
 逆アセンブルリストを見る限り、単純に 4→3→2→1→0→4→3→2→1→0→4→
...と変化するはずである。ところが実際は、0が2回続いたり3が2回続いたり、要するに処理落ちしているかのような状態。そのパターンには規則性がない。
 処理落ちならば他の変数も変化しなくなるはずだが、そうではない。それに加えて謎のRAM内容破損もランダムに発生して来る。RAM内容破損時は処理落ち状態の場合があるが、そうでない場合もある。

 もはやデジタルの世界とは信じられないカオスで、どうにもならない。
 キャラの移動などメインループが、恐らく割り込み処理で行なわれている。ハードウェアによる割り込みをMAMEというソフトで再現しているわけで、仮に
Windows の割り込みを利用しているのであれば再現性が無くなるのも仕方ない。このあたりはどうなっているか分からない。割り込みにフック掛ければ
dsync しないかもしれないが、エミュレート元のハードは仕様が千差万別。ハードに応じて適切な場所にフックせねばならず、元の
MAME がTAS製作の都合など一切考えずに作られている以上どうしようもない。

 それでも単なる dsync にしては、直進中のスマートボムを大外しすることも多い。
 何か重大な見落としをしているのでは?と再検討したら、重大ミスを発見。

中央のミサイルは実は速かった

 移動ルーチンの解析が半端だった。移動ベクトル自体は左右も中央も完全に同一なのだが、移動回数が違う。左右のミサイルは確かに1フレームに3回移動するのだが、中央のミサイルは7回も移動していたのだ。速度が倍以上も違うのに違和感を感じないほど、元々迎撃ミサイルは速い。
 スマートボムを大外しするのは、単に中央から発射していた場合というだけだった。フレーム毎に7回移動する迎撃ミサイルを、3回として計算していたらそりゃ過剰に早く到達してしまう。

written by higashino [ゲーム] [この記事のURL] [コメントを書く] [コメント(0)] [TB(0)]

この記事へのトラックバックPingURL

Comments

TrackBacks

Darkside(リンクエラー修正しました)

Generated by MySketch GE 1.4.1

Remodelling origin is MySketch 2.7.4