summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHiram Anderson <37224753+hjk321@users.noreply.github.com>2021-03-25 22:51:24 -0500
committerHiram Anderson <37224753+hjk321@users.noreply.github.com>2021-03-25 22:51:24 -0500
commit0f12500606cb939e50dce5b36b876e6c4a1f918f (patch)
treee2436b163e602d370ed87b544888f930b5f53ac0
parent90d0d75582cb490d243aabcb9e4a00760cadd35e (diff)
Created Extra save space with two lines of code (markdown)
-rw-r--r--Extra-save-space-with-two-lines-of-code.md44
1 files changed, 44 insertions, 0 deletions
diff --git a/Extra-save-space-with-two-lines-of-code.md b/Extra-save-space-with-two-lines-of-code.md
new file mode 100644
index 0000000..19b0b13
--- /dev/null
+++ b/Extra-save-space-with-two-lines-of-code.md
@@ -0,0 +1,44 @@
+# Introduction
+
+There are plenty of ways to get extra save space in Emerald, but that usually means you need to remove redundant data structures or even entire features from the game. While that is useful (and still recommended), there is also an additional way to score some extra save space, and is completely compatible with any other saveblock-editing changes you've made. The best part? It's only two lines of code.
+
+# How to do it
+
+1. Open `save.h` and find these two lines:
+
+```c
+#define SECTOR_DATA_SIZE 3968
+#define SECTOR_FOOTER_SIZE 128
+```
+
+2. Change those lines to this:
+
+```c
+#define SECTOR_DATA_SIZE 4084
+#define SECTOR_FOOTER_SIZE 12
+```
+
+3. There is no Step Three! You're done!
+
+This gives you an extra 116 bytes in `SaveBlock2`, an extra 464 bytes in `SaveBlock1`, and an extra **1044** bytes in `PokemonStorage`. Have fun!
+
+# Why this works
+
+... okay, now that I've lost about half my audience, a few of you may want to know *why* changing these two lines magically gives you extra save space. After all, the numbers we changed those constants to seem pretty arbitrary. However, there is a good reason for it! Let's take a look under the hood.
+
+So, the 128k save for Pokémon emerald is divided into 32 sectors, of 4 kilobytes each. As you can see in the two lines above, most of that sector contains the actual data of the save blocks, but the last 128 bytes is reserved for "footer" data, and game data is not written there. But let's take a look at what is actually being stored in this footer. Here is the struct for a sector as found in `save.h`:
+
+```c
+struct SaveSection
+{
+ u8 data[0xFF4];
+ u16 id;
+ u16 checksum;
+ u32 signature;
+ u32 counter;
+}; // size is 0x1000
+```
+
+So, we have the `data` array which is the game data itself. Everything else is the footer data we were talking about, which pertains to the save sector itself. But, wait a minute... That's only 12 bytes of footer data, not 128! Also, there's `0xFF4` (4084) bytes of data in `data`, when we saw with the two constants above that only 3968 of those bytes are being written to! That's a difference of **116** bytes in the sector that is completely unused!
+
+All this two line fix is doing is taking the unused bytes from the footer and writing game data to it instead. 116 bytes is not a huge amount, but remember that these bytes are being saved in *all 32 sectors*, which adds up to a combined 3.6 kilobytes of extra space. Not too shabby! \ No newline at end of file