Decomp integration: Difference between revisions

Line 10:

===Using the decomp===

* C injection without needing a separate tool (C of Time).

* Adding/removing lines of ASM without breaking the ROM, since the decomp will shift all pointers automatically. This removes the need for ASM hacks like overlay 36.

* Adding/removing lines of ASM without breaking the ROM, since the decomp will shift all pointers automatically. This removes the need for ASM hacks like [[ExtraSpace|overlay 36]].

* As the decomp progresses, functions will start to be editable in C without needing to know ASM.

* As the decomp progresses, functions can be documented at a more granular level with variable names and code comments, in addition to the symbol-level documentation offered by pmdsky-debug today.

Line 31:

====Patches====

In an ideal world, ASM patches would be obsolete in favor of editing the code directly in the decomp. However, realistically there will need to be compatibility with existing ASM patches. The challenge with ASM patches is hard-coded pointer addresses, which will break if any code change in the decomp shifts the pointers around. There are a couple possible ways to approach this.

In an ideal world, [[ASM Patch|ASM patches]] would be obsolete in favor of editing the code directly in the decomp. However, realistically there will need to be compatibility with existing ASM patches. The challenge with ASM patches is hard-coded pointer addresses, which will break if any code change in the decomp shifts the pointers around. There are a couple possible ways to approach this.

* Apply patches on the ROM built by the decomp. This will require a conversion script that looks at the pointer addresses in the patch and shifts them according to the decomp. xMAP files can be used to find the nearest function to a given address in the patch. From here, an offset can be calculated between the patch address and the nearest function address, then added to the patch address to shift it.

* Modify the decomp files based on the patch. Since the decomp contains the raw assembly, a patch file could be incorporated into the built ROM by modifying the decomp's assembly code according to the instructions of the patch file. However, this may run into issues with functions decompiled to C, as they will no longer contain the original assembly code.

@@ Line 10: / Line 10: @@
 ===Using the decomp===
 * C injection without needing a separate tool (C of Time).
-* Adding/removing lines of ASM without breaking the ROM, since the decomp will shift all pointers automatically. This removes the need for ASM hacks like overlay 36.
+* Adding/removing lines of ASM without breaking the ROM, since the decomp will shift all pointers automatically. This removes the need for ASM hacks like [[ExtraSpace|overlay 36]].
 * As the decomp progresses, functions will start to be editable in C without needing to know ASM.
 * As the decomp progresses, functions can be documented at a more granular level with variable names and code comments, in addition to the symbol-level documentation offered by pmdsky-debug today.
@@ Line 31: / Line 31: @@
 ====Patches====
-In an ideal world, ASM patches would be obsolete in favor of editing the code directly in the decomp. However, realistically there will need to be compatibility with existing ASM patches. The challenge with ASM patches is hard-coded pointer addresses, which will break if any code change in the decomp shifts the pointers around. There are a couple possible ways to approach this.
+In an ideal world, [[ASM Patch|ASM patches]] would be obsolete in favor of editing the code directly in the decomp. However, realistically there will need to be compatibility with existing ASM patches. The challenge with ASM patches is hard-coded pointer addresses, which will break if any code change in the decomp shifts the pointers around. There are a couple possible ways to approach this.
 * Apply patches on the ROM built by the decomp. This will require a conversion script that looks at the pointer addresses in the patch and shifts them according to the decomp. xMAP files can be used to find the nearest function to a given address in the patch. From here, an offset can be calculated between the patch address and the nearest function address, then added to the patch address to shift it.
 * Modify the decomp files based on the patch. Since the decomp contains the raw assembly, a patch file could be incorporated into the built ROM by modifying the decomp's assembly code according to the instructions of the patch file. However, this may run into issues with functions decompiled to C, as they will no longer contain the original assembly code.