近況

1月が過ぎて、もう2月になってしまいましたが・・・
諸事情によりネットでの活動が暫く出来ません。
従ってどの程度になるかわかりませんが・・・Be Naturalの更新を休止します。
予め御了承下さい。

1 Comment »

もう過ぎていますが、12月23日~1月の中旬辺りまで更新作業は停止すると思われます。
何しろクリスマス大晦日正月といろいろ忙しい時期ですので。

そういう訳で、BBSのチェックなども行えませんのでここに予め書き留めておきます。

No Comments »

つまり、IFコードということです。
「もし~なら実行」ということをコード内部で行うことが出来ます。通常はパッド制御などで使用することが多いですが、使用用途は多彩です。簡単な例として、HPが100を超えたら実行、ダメージを受けたら実行などとコードを実行するタイミングを自由自在に操ることが出来ます。その他、レンジチェックコードのようにハングアップ回避のために使用することも可能です。このIFコードを使用する場合終端に必ずENDコードを入力して下さい。ENDコードとはE0コードやF0コードなどのことです。「False」時の設定がされていない場合ここへジャンプすることになります。

コードの判定タイプには16ビット用と32ビット用があり、32ビットは特に細かい設定はありませんが、16ビット用は更に細かい判定設定が可能になっています。判定させたいものによって32ビットタイプと16ビットタイプを使い分けるのがセオリーです。条件タイプは「同値」「違値」「以上」「以下」の4タイプです。「未満」などを設定したい場合は判定する値を上手く設定してやればOKです。

32ビット用16ビット用と共に、ひとつのコードの中で複数の条件分岐を行いたい場合はアドレス部に0x1を加算する必要があります。つまり、以下のようになります。

38000000 0000ZZZZ
14000000 FFFFFFFF
38000001 0000YYYY
14000000 EEEEEEEE
E0000000 80008000

これでZZZZの条件を満たすと0x80000000へFFFFFFFFを書込み、YYYYの条件を満たすと0x80000000へEEEEEEEEを書き込むというコードになります。あれ?アドレス部に0x1を加算するとアドレスの位置がズレておかしくなるだろう!と思うかもしれませんが、おかしくなりません。何故なら、16ビットタイプは偶数アドレスのみ。32ビットタイプは4の倍数のアドレスのみしか指定出来ないようになっているためです。なので、0x1をアドレス部に加算するという行為はコード自体の条件タイプをEndifに変更しているということになります。ZZZZの条件が満たされない場合Geckoが返す結果は「False」となり、通常はE0コードまでジャンプするのですが、ここでは38000001 0000YYYYというEndifが存在するのでここへジャンプして新たに条件チェックを行う、ということになります。

しかし、ここでもし38000001 0000YYYYが38000000 0000YYYYだった場合は二重条件チェックとなり、ZZZZの条件を満たして更にYYYYも満たした場合0x80000000へEEEEEEEEが書き込まれることになります。無論、ZZZZの条件を満たした時点で0x80000000へFFFFFFFFが書き込まれるのでコードを新しく組み立てなおす必要がありますが・・・このようにちょっとコードを書き間違えるだけで複数条件分岐ではなく二重条件チェックになってしまうので、IFコードを複数使う場合は注意が必要です。

勿論この二重条件チェックは何重にもIFコードを重ねることが出来るので、HPが100以上でYボタンを押していて敵からダメージを受けた時のみコードを実行といった複雑な条件を持たせることも可能になりますので、有効活用しましょう。

No Comments »

前回紹介したコードにも DE000000 80008180 というコードを使用していましたが、今回はこのCE/DEコード簡単に解説したいと思います。

まず初めに、これらのコードはどちらも働きは同じでベースアドレスとポインタに代入されている値をチェックするものです。これらのコードはベースアドレスやポインタの値をチェックして、結果が「True」ならばコードの実行を再開しますが「False」である場合はコードの実行を中止するものと考えてください。正確には終端までジャンプするというのが正しいですが、単に続行するか中止するかで考えるとわかりやすいと思います。

しかし、何故このようなコードが必要なのか疑問に思うかもしれませんが、これらのコードなかなか重要な役割を持っています。改造コードを使ったことのある人なら誰でも体験していることだと思いますが、必要ない時にコードを実行してゲームがハングアップしたことはありませんか? 一度ハングアップするとゲーム機ごとリブートしなければならなくなることが多く、そうなると非常に鬱陶しいものです。レンジチェックコードはこの不必要なコード実行を防いでくれるものです。つまり、フリーズする危険性を回避してくれるコードだということです。

主にどんな場面で使用するかというと、変動アドレスに書き込むコードを使用している場合です。この場合に限って非常に有効なコードとなります。ここでもマリオカートWiiを例に挙げますが、前回紹介したアイテム変更コードからDEコードを省いたコードの場合・・・レース中はいつ使っても問題ありませんが、モードセレクト中やメインメニュー画面、もしくはオープニング画面などの場合に使用するとゲームがハングアップするかもしれません。何故なら、このコードに使用しているポインターがレース中のアイテムアドレスのみを指し示しているとは限らないからです。そうとも知らずに常にコードをONにしていると、ポインターがシステムの中枢部分を指し示したり、オフセットではない値を吐き出したりと・・・こういった時にコードをONにしているとシステムの中枢部分をおかしな値で書き換えてしまったり、関係のない場所のデータを改竄してしまうことになります。運が悪いとこのままゲームはハングアップします。これらを回避するためにポインタのレンジチェックを行うわけです。変動する範囲がある程度絞れている場合はその範囲を入力すると効果的ですが、通常はRAMエリア1か2を指定しておけば良いでしょう。コードの形式はDE000000 XXXXYYYY で、コードはベースアドレスやポインタが0xXXXX0000~0xYYYY0000の範囲内であるかどうかをチェックしてくれます。先頭がDEではなくCEならばベースアドレスをチェックします。入力のルールとして、必ずXXXX<YYYYであることが条件です。YYYYの方の値が小さいとコードは正常に働きません。注意しましょう。余談ですが、GeckoOS1.06時代にレンジチェックコードの不具合がありましたが、現在は解消されていますので問題ありません。

また、このCE/DEコードは条件チェックコードという部類のため条件ジャンプコードと組み合わせることが可能です。ここでは詳しいことは省きますが・・・「False」の場合は3行目にジャンプするなどといった細かい設定が可能ということです。

変動アドレスへの書き込みコードを組み立てる場合には必ず絡ませておきたいコードの一つですね。

No Comments »

ここではマリオカートWiiアイテム変更コードを例に解説します。

通常の場合は以下のように組み立てます。
48000000 809C26A8 // RAMから0x809C26A8の値を読み込み、その値をポインタアドレスとする
DE000000 80008180 // ポインタの値が0x80000000 - 0x81800000の間ならば次行のコードを実行
5A010000 FFFFDD9C // 現在のポインタから225Eを減算する
14000000 000000XX // 減算した現在のポインタへXXを書き込む
14000004 00000001 // 減算した現在のポインタに0x4を加算したアドレスへ0x1を書き込む
E0000000 80008000 // ベースアドレスとポインタをリセットし、先頭へ戻ってコードを再実行

これで常にXXのアイテムを手に入れた状態をキープ出来ます。
しかし、常に同じアイテムでは面倒な場合もあります。
そこで、パッド制御式コードの出番です。
パッド(コントローラー)でコードのON/OFFなどの制御をさせる場合は、コードハンドラに用意されている比較コードのイコールタイプを利用します。
このコードは指定したアドレスの値が指定した値とイコールの時のみコードを実行するという働きを持っています。条件が一致した場合どのコードを実行して、どこへジャンプするか、など細かく設定することも可能です。つまり、このコードを利用して、パッドの信号を管理しているアドレスをコード制御の条件としてやればパッドでコードの制御をすることが出来ます。その場合パッドの信号を管理しているアドレスを見つける必要があるのですが、ここではその過程をスルーします。

3834FF00 0000ZZZZ // 0x8034FF00の値がZZZZなら以下のコードを実行
48000000 809C26A8
DE000000 80008180
5A010000 FFFFDD9C
14000000 000000XX
14000004 00000001
E0000000 80008000 //Endif

マリオカートWiiのゲームキューブのパッドアドレスは0x8034FF00です。
つまり、ZZZZで指定した場合のみアイテムを固定するコードが実行されるわけです。ちなみに、0x8034FF00の値がZZZZの値と一致しない場合は「Endif」までジャンプします。つまり、38コードからE0コードの間のコードを無視してベースアドレスとポインタアドレスをリセットしてコードを先頭から再実行する、ということになります。指定したボタンを押さない限りこれらの行動を高速で永遠に繰り返すと考えて下さい。

さて・・・これで、ZZZZに指定したボタンを押した時にXXのアイテムを手に入れる事の出来るアイテムコードが完成しました。しかし、これでは単なるコードのON/OFFが制御出来るだけです。出来るなら、複数のアイテムを好きなときに自由自在に入手して使いたいものです。例えばスターと赤甲羅と巨大キノコとサンダーなど・・・

次は複数のアイテムをパッドのボタンで手に入れる事が出来るコードを作りたいと思います。
簡単な方法を挙げると以下のようになります。

3834FF00 00000084 // 十字キーの下を押すと以下のコードを実行
48000000 809C26A8
DE000000 80008180
5A010000 FFFFDD9C
14000000 00000009
14000004 00000001
E0000000 80008000 //Endif
3834FF00 00000088 // 十字キーの上を押すと以下のコードを実行
48000000 809C26A8
DE000000 80008180
5A010000 FFFFDD9C
14000000 00000008
14000004 00000001
E0000000 80008000 //Endif

単純にコードを2個並べただけですが、これでもコードは働いてくれます。この例の場合、十字キーの上を押すとサンダー、下を押すとスターを手に入れる事が出来ます。これで完成とも言えるのですが、これでは無駄な命令がありコードの無駄遣いになります。一度に実行出来るコードの数は255行です。出来るだけ最適化を行いコードの行数は少なくするのが鉄則です。具体的には、以下のようにコードを組み立てます。

48000000 809C26A8
DE000000 80008180
5A010000 FFFFDD9C
2834FF00 0000ZZZZ //1つ目のボタン
14000000 00000009
14000004 00000001
2834FF01 0000ZZZZ //2つ目のボタン
14000000 00000008
14000004 00000001
2834FF01 0000ZZZZ //3つ目のボタン
14000000 00000007
14000004 00000001
E0000000 80008000 //Endif

先ほどのコードよりも1行少ない上に、こっちは3つのボタンで3つのアイテムを使い分ける事が出来ます。ちなみに、1つ目のボタンでスター、2つ目のボタンでサンダー、3つ目のボタンでトゲゾーです。では、コードがどういった仕組みになっているのか簡単に解説します。

Geckoで使用出来るコードタイプには、書き込み先となるアドレスを管理するレジスタが2つ用意されています。これらのレジスタには、それぞれ「ベースアドレス」と「ポインタ」という名称が付けられています。どちらのレジスタも機能はほぼ同じものだと考えて下さい。コードが実行される際これらのレジスタには0x80000000のアドレスが自動的に設定されるようになっています。つまり、04222200 XXXXXXXXというコードが0x80222200へXXXXXXXXを書き込むという命令になるのはベースアドレスが自動的に0x80000000と設定されているからなんですね。0x81000000以上の場所へ書き込む際にベースアドレスやポインタを弄る必要があるのはこのためです。何故なら、ベースアドレスやポインタを弄らないと0x1000000以上の値をアドレスに加算させることが出来ないからです。

これらのレジスタはコードの実行中、常に変化させることが出来ます。実はこれがWii改造において非常に強力な武器なんです。書き込み先を自在に変化させられるということは、変動するアドレスであっても書き込み先を常に突き止めることが出来るということになるからです。詳しい方法はいずれ本家でも掲載したいと思いますが、これはWiiRDのポインターサーチという機能を使うと楽に行うことが出来ます。

話が少々逸れましたが 04222200 XXXXXXXX というコードはベースアドレスやポインタを変化させる必要がないコードだから、一行で済むだけであって、ベースアドレスとポインタは常に設定されているということです。つまりポインタで例を挙げるなら、4A000000 80000000という一行のコードが先頭から省略されていると考えるとわかり易いです。

そして、更に話を戻します。つまりベースアドレスとポインタの2つの変化するレジスタを使う事が出来る訳ですから、どちらか1つではなく・・・これら2つを有効利用するべきだと言うことです。先ほどの3つのボタンで3つのアイテムを使い分けるコードの場合はポインタを使ってアイテムアドレスを固定させ、ベースアドレスを使いパッドアドレスの値を参照しています。マリオカートWiiのアイテムアドレスは変動するアドレスの為アドレスを固定させることが出来ません。そのため、条件分岐コードを入れてから、アドレスを変動させてアイテムアドレスを突き止めるという方法か・・・その逆の方法で本来はコードを作成します。しかし、一方のレジスタでアイテムアドレスを固定させておき、もう一方のレジスタで条件分岐を行うという方法で、レジスタを2つ使ってやればいちいちアドレスをリセットさせることなく条件分岐を行うことが出来ます。

本来4行目の28コードの時点でアドレスが変化しているためパッドの条件チェックは出来ません。しかし、変化させたのはポインタアドレスであって、ベースアドレスは初期値の0x80000000から変化していません。そのため28タイプのコードが有効利用出来ているということです。ここが38コードであれば、このコードは正常に働きません。何故ならポインタはこの時点でアイテムアドレスへと変化しており、ここにいくら値を加算してもパッドアドレスにはならないからです。マリオカートWiiやスマッシュブラザーズXのコードをGecko公式サイトへ私も投稿しているので、コード作成の際は参考にして下さい。

長くなりましたが、複数の条件分岐を入れたい場合はこのように本来の書き込み先アドレスと条件分岐用のアドレスを別々のレジスタで管理してやれば良いと言うことです。Wii改造を始めたばかりだと、何を言っているのかサッパリわからないと思いますが、複雑なコードを組み立てる上ではベースアドレスとポインタは必須と言っても過言ではないということを忘れないで下さい。

Read the rest of this entry »

2 Comments »
ホットワード padding margin Diary しまいま 活動
割引クーポンまとめ情報 - クー割