Research: Battle Platforms: Adding and Switching

Over the last few weeks, I started investigating Battle Platforms, how they work, and how one might be able to increase the amount of them, for custom platforms such as a lava one, or basically to add a little creative touch to a hack that has special platforms.

I hit a brick wall, however, and only managed to decipher what happens about halfway. I'm posting all my findings here, in the hope that someone else might be able to use this information to their advantage, and be able to find out more about it.

First, the table that stores entries for all the battle platforms begins at 24EE34, and each entry is made of five pointers. The first is a pointer to the tiles that make up the platform itself. The second is a pointer to the platform's tilemap. The third is a pointer to the tiles that make up the secondary animation (Waves splashing, grass waving, etc.). The fourth is a pointer to the tileset of the secondary animation, usually it's a strip of something that scrolls to the left, and then drops down and disappears. And the fifth appears to be a pointer to the compressed palette. This table seems to be repointable, and I did so successfully, although there's no way to access the platforms conventionally.

There's a very easy-to-understand (relatively speaking) routine that loads up the platform required at 0800F260, and it looks as such:

This code, quite simply, gets the value of R0, finds that r0'th entry in the above table, and then goes to the image decompression function at 0800EBC0. Midway, it checks if the value of R0 is greater than 0x13, and if it is, load up slot nine instead, probably as a sort of error-checker.

I have images for what each value of r0 will boot up. Firered has built-in support for twenty battle platforms already, although six are basically the same, with small palette changes. Here are the images, in a spoiler:



Sadly, I wasn't able to find out how the value of r0 is determined. For most of the platforms, they seem to be based on behavior byte of the tile you're on; for instance, standing on a tile with "Very Tall Grass" animation will yield the very tall grass platform, no matter what. The four Elite Four platforms are controlled by a header setting in the map, under "Fight Type". Sonic1 was able to determine that the header setting takes precedence to the behavior byte. And still others, such as the underwater and (I believe) cave and indoor tiles depend on the "Type" value in the header, which can be set to underwater, underground, or inside, respectively.

I managed to develop a routine which would function similarly to Mastermind_X's music hack, allowing me to choose which platform appears in a script, depending on the value of variable 0x800A (chosen because it's hardly used). This routine was successful, for the most part, except it had two key bugs. The first, it would load the wrong tiles and tilemaps for the secondary animation. For example, I would turn all the platforms to sand, but walking on a tall grass tile would make sand-colored tall grass appear behind the player. Secondly, whenever a Pokemon's attack would display a background, such as the move Psybeam, the screen would flash in an infinite loop, I assume trying to load the correct platform, but it not being able to.

The main routine, not the one I added, is called in a rather inconvenient way, using the "relative to PC" branch command, instead of a normal goto, meaning that any sort of custom routine would need to be located in a very specific range of free space. The location of the branch is at 0800F416. Sonic1 was able to help in this regard, since I'd never "hooked" a routine before, and said that the routine must be between 0x8000000 and 0x83FFFFF. The custom routine I added was such:


The main limitation on this code is that it won't accept the standard tall grass platform (0x0), just because I chose 0x0 to mean "don't change". The second limitation is that this change forces all platforms to instead load the one specified in the variable. If I were to do a rewrite of the code, I'd make it so a specific platform would be replaced by another platform, to avoid "water battle sand platform" issues.

One final note: I was able to deduce a few things about the routines that load these platforms. The first is that the palettes are loaded after the platforms are, which I know because the platforms that were switched had the correct palette, secondary animation aside. Secondly, I suspect there might be more to that palette block. All wild battles used two palettes that are somewhat identical in color, one for the platforms, and one for the secondary animation. I'm not 100% sure where this second palette comes from...perhaps another table? And finally, the secondary animation must be loaded from another routine prior to this, because of the aforementioned problems.

I hope this is enough info to get the minds of Pokecommunity turning; I haven't seen any hacks that go much farther then replacing the platform pictures with more awesome and less plain ones, or custom platforms at all, so this might be a neat area to tap into.

Not sure how much this helps, but the RAM location 0x02022B50 contains the byte that determines what battle background is loaded. If you change this byte in VBA's memory viewer, then have the game re-draw the background (just view your Pokemon party and exit), then the background will change. Nothing bad happens, even if you use an attack that temporarily changes the background, such as Faint Attack.

I would expect that an ASM routine that simply changes the byte that is set at 0x02022B50 would fix everything.