Darkside（リンクエラー修正しました）

　ゲーム画面に辿り着いたが、スクリプトを動作させるためには速度や座標をスクリプトから知ることが出来ねばならない。手動でＴＡＳを作るのであれば、画面を見れば分かる。しかしスクリプトは画面を読み取れない。

　ＲＡＭサーチを使って絞り込むが、候補が複数出て来たりヒットしなかったりと、はっきりしないことが多い。最初は適当に確からしいアドレスの値を使用してみる。

　更に大きな問題として、スクリプトでキー入力を設定する際の名前である。
　あるキーが押された状態にしたいとき、具体的にどういう名前でキーを記述すれば良いのか？
　それが記述されているドキュメントは、滅多にお目に掛かれない。キーの名前を間違えて記述すれば、押されたことになってくれない。

　恐ろしく不親切である。
　自分の経験上、同一機種のエミュレーターであっても別のエミュレーターになると、スクリプト上におけるキーの名称に互換性がないことが多い。更にデジタルキーの場合、押されていない場合は
false を放り込むのか？押されている場合は true を放り込むのかそれとも１か？と言った微妙な問題もある。相手はコンピューターだから、すべてが厳密に決まっている。それなのに、厳密に記述されたドキュメントが、どこにも存在しない。

　更に BizHawk の場合は、多機種対応である。スーパーファミコンのパッド入力と、プレステのパッド入力では、パッドが違うのだからキー名称も違う。

　結局のところ、スクリプトでパッド入力を取得し、どのような名称で取得されたかをスクリプトで表示される、という方法しかなさそうなのだ。

function record(buttons)
  for button, value in pairs(buttons) do
    write_log(button)
  end
end
record(joypad.get(1))

　という感じである。write_log は、テキストファイルに出力する自作関数。
　これにより、キーの具体名がズラズラと出力される。
　これにて名称は解決、と思ったがスクリプトをロードした際にエラーが出る。

　このエラー自体は do の記述漏れというケアレスミスだったが、修正してもスクリプトがロード直後にアプリケーションエラーを出す。
　厄介なことに、アナログ入力キーの具体名が、半角空白を含んでいるのだ。をい勘弁してくれよ名称定義する際に配慮しやがれよ！

　そういうことされると、不必要にプログラミング記述が面倒なんだよ！

btn = {}
btn["RStick X"] = 128
btn["RStick Y"] = 255
btn["LStick X"] = 0
btn["LStick Y"] = 0
joypad.setanalog(btn, 1)

　これも試行錯誤したが、いったん配列に個々に代入してやらないと駄目だった。
　だが、遂にネジコン入力をスクリプトで行うことに成功★

　実際のプレイ画面に辿り着くまでに、あれこれキー入力が必要なのが普通である。
　あれこれメニュー選択しなくてはならない。

　ただし、そういう操作は単純で、スクリプトなど不要。
　この画面の直後に、エミュレーターがエラーで落っこちた。エラーは Windows
システム側のＤＬＬで発生したので、原因不明。恐らくは、アプリ切り替え時のトラブルだろう。エミュレーターは、あれこれ同時稼動させると相性の悪いソフトが存在するようだ。

　問題は、これで記録中のムービーが飛んで、記録済みフレーム数０になってしまった。これまでの苦労がパーである。そう思ったが、途中のステートセーブがすんなりロードできた。
　以前のバージョンでは適当なダミームービーを用意すれば、どんなステートでもロードしてムービーに仕立て可能だったが、最新バージョンは同一ムービーとみなした場合だけステートをブチ込める仕様みたいだ。
　ともあれ、大幅な手戻りは回避できた。メニュー操作は単純だが、ＴＡＳである以上は最速で操作せねばならない。だから、案外手間が掛かって面倒なのだ。

　わざわざネームを入れるのは大幅なフレーム数のロスだが、以前書いた通りレースゲームは特別だと考えている。ゲームそのものがタイムの追求なので、ゲーム内タイムの最速さえ目指していればＴＡＳとして成立する。
　もちろん、ネーム入れなどの寄り道をするとしても、寄り道なりの最速でなければならない。人力では不可能な高速ネーム入れというのも、ＴＡＳを楽しむ一要素だろう。

　このような地道な作業の裏では、F-ZERO 用の探索スクリプトが２並列で走っている。相変わらず
faster 解は発見できていないが、のべ１００時間単位でスクリプトを走らせ続けて未だにエラーは１度も発生していない。
　以前に比べるとスクリプトの安定性が劇的に向上しているため、とにかく次々に走らせて探索しまくって、その間に別のＴＡＳを製作すれば良い。

　BizHawk におけるネジコンＴＡＳの製作に慣れるために、このモータートゥーンを使用し、１つだけＴＡＳを作ったら本丸の初代リッジレーサーに進む予定である。
　初代リッジレーサーのＴＡＳが皆無なのは、ネジコンＴＡＳの製作環境が存在しなかったのが大きな理由である。しかしそれだけではなく、ＴＡＳ製作自体が非常に大変だというものある。恐らくは初代 F-ZERO に匹敵するほど大変である。最速を追求すれば、追記が何回になるのか想像もできない。

　さて問題は、そもそも仮想パッドでネジコン入力が可能かどうかである。
　仮に現物パッドで�Uキーが認識されないだけであれば、仮想パッドなら認識されるかもしれない。
　試してみると、症状は全く同じ。ブレーキが使えないし、速度は上がらない。

　だが、考えてみるとＴＡＳ製作限定なら�Uキーが使えなくても何とかなる。
　モータートゥーングランプリの場合、人間が遊ぶならブレーキを使いたくなるが、ノーミスプレイならブレーキは不要である。
　リッジレーサーではＴＡＳであろうともブレーキは必須だが、ゲーム内のコンフィグでパッドのキー割り当てを変更してしまえば良い。リッジでは、アクセルもブレーキもデジタルキーで問題ない。自分は「コマンド入力で走るレースゲーム」と呼んでいる。リッジレーサーのＴＡＳでネジコンが必須なのは、ハンドリングだけの問題だ。

　そこで、ネジコンのキー入力処理で、�Uボタンに常に０が書き込まれるようにしてみた。
　すると見事に、アクセルで普通に加速できるようになった。仮想パッドでも同様に、ちゃんと加速できる。
　リッジレーサーでも確認する。コンフィグに入ると、ネジコンのグラフィックになっていて、ソフトからネジコンが認識されているのが分かる。これで、タイプＥ〜Ｈを選ぶと、デジタルキーでアクセルとブレーキが使える。そして遊んでみると、普通に走れる。ブレーキも利く。よし、どっちのソフトもネジコンでＴＡＳが作れるぞ。

　このような余分なコンフィグ処理は、ＴＡＳ的にはフレーム数を増大させる禁忌である。しかしレースゲームの場合、総フレーム数ではなくゲーム内タイムの最短化という方針は受け入れられ易い。

　プレイ可能になったので、ムービーを記録してみる。
　ネジコンでプレイを行い、記録。それを再生すると、完全に再現された。ネジコン使用のプレイが、ムービー記録できている。記録されたムービーの諸元を見ると、コントローラーの項目は
octoshock とだけ記載されている。そこで試しに、無改造の BizHawk で再生させてみた。結果は、全フレームがラグフレームとなって一切の入力が再生されなかった。

　実際にＴＡＳ製作を始めるなら、仮想パッドの一部が隠れているのはマズい。幸いにして、再配置に成功。コンパイルすると、ほぼ問題なし。デジタルボタンがタイトルを一部隠すなど完成度が低い部分は残っているが、実用上問題無いので余計な作業時間は使わないことにする。

　ここでコンパイルしたせいかどうかは不明だが、仮想パッドで�Uキーが入力可能になった。現物ネジコンでは相変わらず入力できないため、実機感覚で遊ぶことはできない。しかし、ＴＡＳ製作に限定すれば、問題なくなった。
　ＴＡＳ製作の障害はあと１つだけ。Lua スクリプトでアナログ入力を設定できなければならない。だが、これは動作が未確認なだけで、問題なく設定できる可能性が高い。というのも、仮想パッドの入力がそのままネジコンに反映されたからである。スクリプトのアナログ設定も、そのまま反映されるだろう。

　仮に反映されなかった場合は、そのとき改めて追加改造すればいい。

　ネジコンが使えるようになったが、不完全。

　アクセル全開にしても、１２８キロまでしか上がらない。本来なら、３００キロを超える。
　更に、ブレーキが認識されない。正確に言えば、ネジコンの�Uボタンが認識されない。config.ini をどう記述しても、�Uボタンは無視される。

　そこで、仮想パッドを表示させる。psxjin にも同様のものがあったが、アナログ入力をパッドではなくパソコン上で行えるものだ。これにより、正確なアナログ値を入力可能となる。ＴＡＳ製作には必須と言って良い。
　だが、画面が崩れている。これでは右スティックのＸやＹの値が読み取れない。現在どんな値になっているのか確認できない。微妙に使い物にならない。

　それでも仮想スティックをドラッグして動かすことは可能なので、動かしてみる。非常に遺憾なことに、psxjin のようにカーソルキーで値を１ずつ変化させることはできない。コンボボックスの矢印をクリックすれば可能だが、カーソルキーに比べると操作性が悪い。
　それ以前の問題として、下半分に移動したとたんエラーが出て止まった。
　をいをい・・・このプログラム作成に全く関与していない第三者の自分でさえ、何が起きたのかすぐに分かったぞ。

　アナログ値は０〜２５５なので、中央は１２８である。原点は (0,0) ではなく (128,128) なので、先に座標から１２８を引いておかねばならない。
　修正すると、すんなり仮想パッドが使えるようになった。右スティックの数値は隠れたままだけど。

　これほど単純な不具合が放置されているというのは、関係者が誰一人として仮想パッドを使ったことがないのがほぼ確実。アナログパッドを使ったプレステのＴＡＳ製作も行われていないのだろう。少なくとも、思い切りマイナーってことだ。
　なるほどこの惨状なら、ネジコン対応がずっと放置されていても不思議はない。

　ちゃんとネジコンが選択されているかどうか調べようと、デバッグでブレークポイントを設定する。ところが、通るはずなのに通らない。いや、妙なメッセージが表示される。このドキュメントのシンボルが読み込まれていません。だと？
　をいをい、普通はデバッグモードでコンパイルしたら、シンボルは自動生成されるものだろ。わざわざ明示的に設定しないとシンボルが生成されないなんて、前世紀の遺物だぞ。

　とはいえこれ一応はＭ＄の最新環境である。コンパイルしたのにシンボルが生成されないのは、おかしい。他に原因があるかもしれない。
　そう考えてネット検索すると、出るわ出るわ・・・これポピュラーな障害だったのかよ！
　無料版というのがネックになるのは、このような場合である。とんでもない不具合だが、文句を言えない。しかし、ブレークポイントが設定できないのでは、恐ろしく使い物にならない。

　よし、こうなったら強制停止だ。
　ブレークさせたい位置に、int a=1/0; と記述する。０による除算だから、実行されれば必ずエラーでブレイクする。ところが、コンパイルされない。あ！
　要するに、ブレークポイントを設定しようとしたのは、メインの実行ファイルに含まれていない場所だったのだ。
　BizHawk は sln ファイルが多数存在し、パッド入力関係は別のソリューションでコンパイルせねばならないのであった。そりゃあシンボルが生成されないのは当たり前だ（汗）
　Ｍ＄濡れ衣でした。

　今度はブレークポイントが効いているようだが、実行すると即座にエラー。これは実行ファイルではなく、ＤＬＬらしい。

　最初のソリューションに戻ってから、ブレークポイントを設定する。ソリューションにＤＬＬは含まれていないが、シンボルは生成されたので読み込みされる。
　今度は、ブレークポイントが機能した。

　type の値は、ちゃんと negcon になっている。もちろんオリジナルの BizHawk では、ここに negcon という値で入ってくることはない。例え入って来たとしても、対応する分岐は記述されていない。
　ともあれこれで、調査が可能になった。