アルゴリズムは以下の通りです。

FEBuilderGBAが知っている領域のデータをすべてファイルに書きだします。
↓
無改造ROMにそのデータを取り込みます。
↓
クリーンアップしたROMを作成します。

ようするに、既存のROMから、Buildfileのようなものを自動生成していると考えれば理解しやすいかもしれません。
ただし、生成するデータは機械で読むことを前提としているため、buildfileよりも可読性は低下します。

FEBuilderGBAが知らないデータ構造でも、LDR参照を頼りに追跡するので、動作します。
FE8がもっとも正しく動作します。
FE7,FE6だと未知のデータ構造がまだたくさんあるので、失敗する可能性が高いです。


また、以下のような、途中から複雑な実行されるコードには対応していません。
EAで書くとしたら以下のようなパッチです。

org 1234
jmpToHack(my_program + $50)

my_program:
#incbin "my_program.dmp"

my_program.asm
.thumb
MyLib:
push {lr}

pop {pc}


.org 0x50
Main:
bl MyLib
bl MyLib
bl MyLib

ようするに、指定されたポインタより上の相対アドレスに対して、BLで相対ジャンプしているコードです。
このようなコードは、めったにありませんが、FE8Jでは、古い2つのパッチがこの書き方で書かれていました。
このコードが、リビルド対象のアドレスである 0x01000000にあると、リビルドは失敗します。

FE8Jの古い2つのパッチは、新規に書き直したバージョンがありますので、リビルドを利用する場合は、そちらを利用してください。

再構築するときに、既にあるBINデータを共有してサイズを小さくすることがあります。
例えば、ROM内にバイオリンの楽器データがあるのに、まったく同じバイオリンの楽器データを追加するのは容量の無駄です。
REBUILDでは、このようなデータ構造があると、自動的に共有します。(ログにはSHARE!と表示されます。)

だいたい2MB-11MBほどの圧縮効果があるようです。
これは、昔作られた改造が楽器データを共有化していないためです。

怪盗
31MB
↓
19MB

ユグドラ
28MB
↓
21MB

女王の剣
21MB
↓
18MB

昔のzalhman's song editorは、楽器を共有化ができませんでした。
現在、私が拡張したバージョンやFEBuilderGBAは、楽器の共有化を自動的に行います。
よって、10MBの容量減というのは、あまり期待しない方がいいです。
だいたい2-5MB程度だと思われます。

なお、Buildfileで作られた改造に対しても、わずかではありますが、圧縮効果があるときがあります。
ただし、効果はわずかなので、気にする必要はありません。

通常、REBUILDを利用する必要はありません。
ROM容量が限界である32MB近くになったときに、検討すればいいでしょう。
むやみに利用すると、バグを発生させる原因になるので、乱用しないでください。

ROM.GBAをリビルドすると、ROM.R.GBAというファイルが作られます。
ROM.R.GBAが、リビルドされたROMです。

リビルド後は、必ずクリアテストをしてください。
もし、何か間違いがあったら、危険なので、リビルドしたROMは破棄してください。
リビルドした結果壊れたROMの修復は、とても困難だからです。
よって、リビルド結果を採用するかどうかのフルテストが絶対に必要になります。

ROM.gba  //ターゲットROM
ROM.R.gba //rebuildしたROM (Rマークが入ります)
ROM.R.rebuild.log.txt //リビルド結果のログファイル

ROM.R.rebuild //リビルドスクリプト
rebuild_bin //ポインタが入らないバイナリデータを保存するディレクトリ.画像や楽器データ等
rebuild_ifr //ユニットやクラスなどの表形式のデータを格納するディレクトリ
rebuild_mix //ポインタが入るデータを格納するディレクトリ

このフォーマットは、機械で読むことを前提としています。
手書きするべきではありません。
ただし、@BIN以外はテキスト形式で格納しています。

数字はすべて16進数表記です。
区切りは、半角スペース1つ。
ポインタでない限り1バイト単位です。
ポインタだけは、4バイト固定です。

EAでいう POIN labelに相当する.
例:@08123456

EAで表現すると以下のようになります。
POIN _08123456

アンチハフマンポインタです。
テキストデータをアンチハフマン形式で格納している場合に利用します。

例:`08123456

開始アドレスからの相対位置を記録する。
楽譜などによくつかわれる.

例:+123

特別な理由がない限り、偶数でポインタを記述します。
ASM関数へのポインタの場合、 +1 した領域も探索します。

例:&08123456
これは、08123456と&08123457 の両方にマッチします。

フォームデータを表します。
先頭に必ずINDEX番目が入ります。
以降は、データが16進数表記で続きます。

ポインタが一切入らないバイナリデータ
画像など.

ポインタが混ざるデータです。

ポインタが混ざるデータ LZ77に圧縮して利用する。
戦闘アニメのフレームデータです。

定義のみ 無変更のアドレスで利用される.
EAで書くならば、何も定義しないラベルです。

org $123456
_123456:

対応する無改造ROMのCRC32のハッシュです。
このハッシュを元に無改造ROMを特定します。

このアドレス以降を再構築します。
通常は、0x01000000 になります。