From c29cb285b4827c90e281e127074b69d19fa64e29 Mon Sep 17 00:00:00 2001 From: DavidJCobb <831497+DavidJCobb@users.noreply.github.com> Date: Thu, 16 Nov 2023 02:17:02 +0100 Subject: [PATCH] Updated Implementing Catch EXP (markdown) --- Implementing-Catch-EXP.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/Implementing-Catch-EXP.md b/Implementing-Catch-EXP.md index ca28bde..16bdd80 100644 --- a/Implementing-Catch-EXP.md +++ b/Implementing-Catch-EXP.md @@ -2,7 +2,7 @@ Beginning with Pokémon X and Y, you could earn EXP by catching a Wild Pokémon. This tutorial has two parts. The "[Figuring it out](#Figuring-it-out)" section walks you through the process of figuring out how to implement Catch EXP from scratch: looking at game systems, understanding them, making code changes, testing them, and fixing bugs as they come up. The "[Just the code changes](#Just-the-code-changes)" section lists only the three relatively small code changes you need to make in order to get a bug-free Catch EXP feature. -The "Figuring it out" section is a much, much longer read; this is because I try to walk you step by step through how to implement something like this, including finding functions we need to edit and reasoning about what could be causing some of the bugs we run into when setting this up from scratch. If you're not used to making these kinds of edits, or if you struggle with troubleshooting bugs, I think it might be a good idea to tough it out, read all this *mucho texto*, and see if it can teach you anything about solving the kinds of problems you run into when making code changes in Pokémon Emerald. +The "Figuring it out" section is a much, much longer read; this is because I try to walk you step by step through how to implement something like this, including finding functions we need to edit and reasoning about what could be causing some of the bugs we run into when setting this up from scratch. If you're not used to making these kinds of edits, or if you struggle with troubleshooting bugs, I think it might be a good idea to tough it out, read it all, and see if it can teach you anything useful. # Figuring it out @@ -261,7 +261,7 @@ Let's select register `0x4000018: BG2HOFS`: "background 2 horizontal offset." ![A screenshot of mGBA's I/O register view, pointed at BG2HOFS. Bits 5, 7, and 8 are set, producing a value of 416, and mGBA shows both the bits (as checkboxes) and the human-readable value.](https://github.com/pret/pokeemerald/assets/831497/4c4b41e9-e543-4ed3-abd6-8726a364b3fb) -According to this, there's a horizontal offset of 416 pixels. Let's try unchecking all of the checkboxes and clicking "apply," and see if that fixes anything, and... nothing happened! If we switch to any other I/O register in mGBA and then switch back to `BG2HOFS`, then it shows 416 again. It's like we never even changed the value. Did mGBA mess up somehow? Or is the game somehow *re-shifting* the background every frame, as if it just *really doesn't want* us messing with it? Where could the code be doing that? +According to this, there's a horizontal offset of 416 pixels. Let's try unchecking all of the checkboxes and clicking "apply," to force the offset to zero, and see if that fixes anything, and... nothing happened! If we switch to any other I/O register in mGBA and then switch back to `BG2HOFS`, then it shows 416 again. It's like we never even changed the value. Is the game somehow *re-shifting* the background every frame, as if it just *really doesn't want* us messing with it? Where could the code be doing that? Well, this problem we're having -- it only happened when we leveled up, right? How does that work? @@ -269,7 +269,7 @@ How does leveling up... ...in battle... -It... It's a script command. Battles use tons of scripting; the script commands are always a good first place to look for things. +It's a script command. Battles use tons of scripting; the script commands are always a good first place to look for things. ## Let's look at `drawlvlupbox` @@ -302,7 +302,7 @@ Aha! They're placing that banner on BG layer 2, so they want to shift the layer If we go back to our "successful catch" script and read it, one command should jump out at us: `displaydexinfo`. I bet the C code for that will be named `Cmd_displaydexinfo`. Let's find it. -Looking at the code, we can see that this is *yet another* script command that runs itself over and over. This time, though, it's because it needs to wait for you to click through the Pokédex entry before it allows the script to continue. We can see that in `case 1`, it calls a function named `DisplayCaughtMonDexPage`, so let's reset the battle-specific BG variables *before* we call that. In fact, let's reset all of them just to be real sure. When we looked at the Pokédex screen's BG layers in mGBA, we saw that they're all set up so that they'd only display properly if they're not shifted. +Looking at the code, we can see that this is *yet another* script command that runs itself over and over. This time, though, it's because it needs to wait for you to click through the Pokédex entry before it allows the script to continue. We can see that in `case 1`, it calls a function named `DisplayCaughtMonDexPage`, so let's reset the battle-specific "BG layer 2" variables *before* we call that. In fact, let's reset all of the layer offsets just to be real sure. When we looked at the Pokédex screen's BG layers in mGBA, we saw that they're all set up so that they'd only display properly if they're not shifted. We've seen `gBattle_BG2_X`, we know there are four BG layers, and we know that computers count from 0 rather than 1, so we can guess the other variable names easily enough (and we can double-check them with Ctrl + F to make sure). ```diff case 1: