Research: [UNFINISHED] Emerald Animations: Codes and Offsets Database

Jeesh · Nov 20, 2016

THIS THREAD IS VERY UNFINISHED, BUT IT IS BEING WORKED ON. IF YOU WANT TO CONTRIBUTE, FEEL FREE TO POST IN THIS THREAD AND I WILL ADD IT TO THE MAIN POST.
erhem.
I don't know if there exists a thread for this topic, but it's probably buried, so here's a new one!

Howdy do, my fellow communitees. Lately, somethings been bugging me in my ROM Hacking career: The Pokémon Emerald Battle Sprite animations. Y'know, these things:

lookit the cute widdle flygon d'awwww
And the question that stirs in my mind: "Are they worth it?" Multiple sources of Emerald ROM hackers say its best to disable them, because they cause to much unnecessary work to be done, whether it be in sprites, animation paths, or frame delays.
However, I say NAY!
I am a firm believer that the animation aspect of Pokémon Emerald is one of the elements that distinguishes it from the rest of the Gen 3 ROM hacking roster, and for that reason, I have decided to help spread my knowledge on the topic, hopefully encouraging hackers young and old, novice and veteran, to include this cool stuff in your hack.
In this thread, the discussion of animation encoding, such as hex values, offsets, and other little goodies will be partaken, to give those Emerald hackers an easier approach to the topic.
Now you might be thinking: "Oh, no! But I only have 1 frame sprites! How am I supposed to make 2 frames? I can't art!" Well have no fear, because there is already a thread where ROM hackers and pixel artists throughout the community are working their magic to make that a reality! You can check out their snazzy work by clicking this beautiful string of blue words.
Without further ado, lets get into the data. Lets start with...

Front Animation Table
In your average Pokémon Emerald ROM, the average offset for this will be located at 3299EC. This table decides how the Pokémon will move and change size or color. There are 150 different animation paths, and so far I've only gone up to 52, which is the last seen used path. NOTE: THE PATHS COUNT UP BY HEXADECIMAL CODE.
Here's how you can change the path (and this applies to ALL 1 byte tables): When you find the offset, you'll have to do a bit of manual searching to find the mon you're looking for, but it shouldn't be that hard. Each Pokemon takes up one byte (aka two letters/numbers, like FF or 00) in the code. So changing that simple two digit/letter byte to any of the ones listed in the spoiler below will change that animation to the animation you chose. The spoiler contains a brief explanation, some with examples, of the animation the byte code entails. Again, there are 150 different paths, but 52 is more than enough if you want to do a simple animation hack.
FRONT ANIMATION PATHS

Spoiler:

Back Animation Table
This is the table for back animation sprites, or the sprites that show you the butt of the Pokemon. These animations, as least as far as Gen 3 and Diamond and Pearl, are 1 frame, and we don't have a very sure idea as to how to make it 2. However, it is located at offset 60A8C8. As well as the front sprite animation paths, these codes are 1 byte long, but unlike the front animation paths, it starts with the ? 'mon instead of Bulbasaur. Coming soon is a good, long list describing each one.

Animation Delay Table
Not much I know about this as of late, but I believe that it has to do with when and how many times the 'mon changes to it's 2nd animation frame. Most 'mons change their frame once, but those like Tailow who spastically flap their wings, they have a much larger amount of frame changes. This must be the table that decides that. Each code is 1 byte long, starts with Bulbasaur. It is located at the offset 329B87. Coming soon is a good, long list describing each one.

Frame Control Table
...
Oh dang.
Maybe this is the table for the description I just gave.
Advanced hackers if you know pls help
For whichever, I'll be coming atcha with info later.

Animation Rotating and Scaling Table
This is a table that isn't really necessary to touch. It is the table that holds aaaaaaall the info for movement paths and resizing and stuff. Everything that moves or changes in a Pokemon's front sprite movement path. Since it's like the basis of all the other tables, I'd recommend leaving this one alone. Unless you REEEEEAAAALLY want to change a movement path. But AGAIN. 150 PATHS.
It's located at offset 60AA88 btw.
That's all so far. Expect updates as soon as December 5th. I'm just getting started with this.

DizzyEgg · Nov 21, 2016

Jeesh said:
Pokemon Animations

*clap* *clap* *clap*

Finally someone who recognized the issue. I've made a post about this recently, though it didn't get many replies. Now, let's throw some offsets:

Code:

083299EC front_animation_table: one byte each entry; starts with Bulbasaur
0860A8C8 back_animation_table: one byte each entry; starts with ? Mon
08329B87 animation_delay_table: one byte each entry; starts with Bulbasaur
08309AAC frame_control_table: it's a pointer to two or three pointers that point to something. The first pointer is always the same. Not sure what this exactly does(It's used in Transform's animation though). Starts with ? Mon and ends on the last Unown.
0860AA88 animation_rot_scaling_table: (the functions responsible for moving a front sprite)

I'd also like to clarify one thing about animations. All animations can be either one or two-frame. The function that checks if a poke has two-frame animation is located at 0806F0D4. Spinda, Deoxys and Unown are the only pokemon who use juts one-frame.

With that in mind we can modify and add new animations as well as keep them and have expanded pokemon use one-frame ones.

And one more thing, the pokemon expansion in my signature expands all those tables.

Jeesh · Nov 22, 2016

DizzyEgg said:
*clap* *clap* *clap*

Finally someone who recognized the issue. I've made a post about this recently, though it didn't get many replies. Now, let's throw some offsets:

Code:

083299EC front_animation_table: one byte each entry; starts with Bulbasaur 0860A8C8 back_animation_table: one byte each entry; starts with ? Mon 08329B87 animation_delay_table: one byte each entry; starts with Bulbasaur 08309AAC frame_control_table: it's a pointer to two or three pointers that point to something. The first pointer is always the same. Not sure what this exactly does(It's used in Transform's animation though). Starts with ? Mon and ends on the last Unown. 0860AA88 animation_rot_scaling_table: (the functions responsible for moving a front sprite)

I'd also like to clarify one thing about animations. All animations can be either one or two-frame. The function that checks if a poke has two-frame animation is located at 0806F0D4. Spinda, Deoxys and Unown are the only pokemon who use juts one-frame.

With that in mind we can modify and add new animations as well as keep them and have expanded pokemon use one-frame ones.

And one more thing, the pokemon expansion in my signature expands all those tables.

Gee, thanks! I try to help when I can :D

Also, applied your knowledge to the main thread.

Also, I retried your Pokemon expanding tool after I BootCamp'd Windows 10 and worked it out there. IT WORKED! Thats how I was able to test all this. So thanks! Sorry I doubted you.

DizzyEgg · Nov 22, 2016

Jeesh said:
Gee, thanks! I try to help when I can :D

Also, applied your knowledge to the main thread.

Also, I retried your Pokemon expanding tool after I BootCamp'd Windows 10 and worked it out there. IT WORKED! Thats how I was able to test all this. So thanks! Sorry I doubted you.

Just one thing. The delay table is the number of frames to wait before starting animations. So if you were to set it to FF, you'd have to wait a bit before it would move. The in-game pokemon that I know has it set to some 'high' value is Wynaut. Check for yourself it doesn't animate the moment it appears on screen.

Lord Comquat · Nov 24, 2016

Very helpful. Really wish there could be a video or something showing all of the animations, including the unused ones, though.

Jeesh · Nov 24, 2016

Lord Comquat said:
Very helpful. Really wish there could be a video or something showing all of the animations, including the unused ones, though.

That can be arranged. If enough people request I might just do one.

Aw heck, I might do one anyway, because visualizing them is so much better than explaining them. No promises though. {XD}

Gamer2020 · Nov 25, 2016

Jeesh said:
That can be arranged. If enough people request I might just do one.

Aw heck, I might do one anyway, because visualizing them is so much better than explaining them. No promises though. {XD}

Gifs of all of them might be a bit better in my opinion but that's just me.

Jeesh · Nov 27, 2016

Gamer2020 said:
Gifs of all of them night be a bit better in my opinion but that's just me.

But I mean, what's an easy tool to make GIFs with? I figure a video is better for this type of stuff.

Deokishisu · Nov 28, 2016

Doesn't Bulbapedia have all the GIFs of Emerald Pokemon moving around?

BluRose · Nov 28, 2016

Deokishisu said:
Doesn't Bulbapedia have all the GIFs of Emerald Pokemon moving around?

#canconfirm

EDIT: oh rip, a few pokémon are cut off because of 64x64 limit. not in-game of course, but on bulbapedia

Jeesh · Nov 28, 2016

Deokishisu said:
Doesn't Bulbapedia have all the GIFs of Emerald Pokemon moving around?

Well, technically yes, but only up to path 52. There are, like 150 animation paths that average Emerald animations barely even scratch the surface with. New gifs would have to be created for those.

EDIT: As a matter of fact, for the first 300 something Pokemon, heres a website that has the legitimate gifs, displaying the first 52 paths.

And they work in the forum! Watch:

Artemis64 · Feb 26, 2017

Here's something I've done before:

Artemis64 said:
I'm not sure if this has been posted somewhere else, but... To those people who want to expand the number of Pokémon on Emerald while retaining the animations: Step 1:

Spoiler:

You need to repoint the table that indexes all of the Pokémon front sprite animations. Open up a hex editor, go to 3299EC, copy 0x1B8 or 411 bytes of data into free space. You need to add as many 00s as there are new Pokémon after the end of the table. Repoint the table to your new location. There should be 4 pointers to repoint.

Step 2:

Spoiler:

Next, you need to repoint the table that indexes all of the Pokémon back sprite animations. Go to 60A8C8, copy 0x1B8 bytes into free space, then add the 00s again. Repoint the table. There should only be one pointer at 17F488

Step 3:

Spoiler:

Now, you need to repoint the table that controls the timing of the Pokémon frame switching. Go to 309AAC, select 0x6E0 bytes of data, and then copy into free space. Repoint it, there should be 5 pointers to the table. Now, how the table works is that it has pointers to certain strings of data that control the timing. Thus, we need to add pointers to the end to prevent glitches. The timing parameters that you should use vary between Pokémon and different versions of said Pokémon's sprite. For instance, Swalot's timing pointer is well-used for jumping frames and so on. Since there is no known index for the timing, the method I use is to observe different Pokémon animations in Emerald then choose from there. Also, when you repoint the normal palette table (the one at 0x303678), you have to index every palette properly. What I mean by this is that, for every entry of a Pokémon's palette: 70 6E C3 08 0B 00 00 00 You have to add 0x1 and write the bolded bytes in little endian form, as the front sprite animation routine uses this to determine which front sprite switching offset is to be used. So for example, for Pokémon 0x1E9 (#489): XX YY ZZ 08 E9 01 00 00 where ZZ YY XX is the offset where the palette is stored. Credits to PurpleOrange for spotting the bug and Sky High for fixing it.

Step 4:

Spoiler:

So, there is one final table we need to repoint. This table controls the amount of time that passes before the animation of the Pokémon is executed (thanks PurpleOrange). Go to 329B87, select 0x1B8 bytes of data (one for every Pokémon), then copy into free space. Now add as many 00s on the end as there are Pokémon. You can change this later to a higher number to delay the amount of time before the animation takes place. Repoint the table, there should be 2 pointers to it.

Step 5:

Spoiler:

Finally, the limiters. In your hex editor, go to 0x34BFE and overwrite it with 07 E0 (for the sprites), and then go to 0xA5FEE and overwrite that with 03 E0. That's it!

As for the structure of the animation tables, here's what I know: There are 2 index tables, which I call the front animation index and back animation index tables, that basically are a bunch of numbers, one per mon, that control which animation plays. The animation played varies from 00 to 96, or a total of 151 animations, each of which is unique. These 2 tables are at 3299EC and 60A8C8 respectively. Then, there's another table at 309AAC which basically controls how long each frame stays on the screen. There's one pointer per mon that points to a string of data that controls the timing; I have no idea how the pointed-to data works. However, the data in this table isn't the only thing controlling how the timing runs; apparently, the numbers that come after the pointer in the front/back sprite/palette tables (e.g. 0B 00 for Pokemon 0xB) determine which pointer is used. This seems to also apply for the front and back sprite animation tables as well. Finally, there's a table at 329B87 that controls how long the animation is. This table is structured as one byte per mon, and the shortest animation duration value is 00, with higher values translating to longer duration of animation. Hope this helps.

Wesley FG · Apr 20, 2017

ok my contribuition for it i really love it
all numbers here are DECIMAL perfect for work with PGE

i make the gifs for better compreension, sorry for some bad quality

Front Sprite Animation List

Spoiler:

Back Sprite Animation List

Spoiler:

WannaCPY · Apr 24, 2019

Wesley FG said:
ok my contribuition for it i really love it
all numbers here are DECIMAL perfect for work with PGE

i make the gifs for better compreension, sorry for some bad quality

Front Sprite Animation List

Spoiler:

00 -

01 -

02 -

03 -

04 -

05 -

06 -

07 -

08 -

09 -

10 -

11 -

12 -

13 -

14 -

15 -

16 -

17 -

18 -

19 -

20 - I need make i gif (no used in game)
21 -

22 -

23 -

24 -

25 -

26 -

27 -

28 -

29 -

30 -

31 -

32 -

33 -

34 -

35 -

36 -

37 -

38 -

39 -

40 -

41 -

42 -

43 -

44 -

45 -

46 -

47 -

48 -

49 -

50 -

51 -

52 -

53 -

54 -

55 -

56 -

57 -

58 -

59 -

60 -

61 -

62 -

63 -

64 -

65 -

66 -

67 -

68 -

69 -

70 -

71 -

72 -

73 -

74 -

75 -

76 -

77 -

78 -

79 -

80 -

81 -

82 -

83 -

84 -

85 -

86 -

Back Sprite Animation List

Spoiler:

01 -

02 -

03 -

04 -

05 -

06 -

07 -

08 -

09 -

10 -

11 -

12 -

13 -

14 -

15 -

16 -

17 -

18 -

19 -

20 -

21 -

22 -

23 -

24 -

25 -

Vlw mano, isso vai me ajudar muito.

Supercookie07 · Jun 26, 2021

This may be an old thread, but here's some more info on the frame control table:
Like stated before, the table is located at 0x309AAC, and has one pointer per Pokémon. These pointers point to two or more (usually two) pointers, starting at 0x308CBC.

The first pointer always points to 0x2FF538, which is basically a blank frame switcher, telling the sprite to only use the first frame. Not exactly sure why this is pointed to in every entry, although pointing the pointer to actual frame data switches the frames while in the starter select menu, so it may be related to that.

The second pointer points to actual frame switching data, starting at 0x305F68. The data is written like this:

Code:

0X 00 YY 00 0X 00 YY 00 ... FF FF 00 00

X is the frame that is shown, it can be either 0 or 1, YY is how long the frame is shown, and FF FF 00 00 signifies the end of the string. The ... can be replaced with more entries like the first 4 bytes. Pokémon like Golbat have a lot of entries while some Pokémon like Bulbasaur and Lugia have only two or three.

A few select mons have more pointers, though I'm not exactly sure what they do or why they're there.

I used Dizzy's PokeExpansion and used more free space to create my own frame switching data, though oddly enough, when I repointed the new mons to the new data, they still only used one frame, and when I changed the pointers of the old mons to point to the new data, it worked perfectly. There must be something that is causing the new mons to only use one frame.

Also stated before, at the end of each normal palette entry, there's an index that apparently the front animation routine uses to determine what pointer the mon should use, and seeing as the first pointer of every frame switching entry only uses one frame, that might be what's happening here.

As of now, this is all I have. Anybody who knows about why this is happening feel free to help.

Research: [UNFINISHED] Emerald Animations: Codes and Offsets Database

More options

Jeesh

I just wanna hack Emerald.

DizzyEgg

Jeesh

I just wanna hack Emerald.

DizzyEgg

Lord Comquat

Jeesh

I just wanna hack Emerald.

Gamer2020

Accept no Imitations!

Jeesh

I just wanna hack Emerald.

Deokishisu

Mr. Magius

BluRose

blu rass

Jeesh

I just wanna hack Emerald.

Artemis64

Wesley FG

Pokémon Kalos Advance !! Gba Hack

WannaCPY

Supercookie07

uhhhhhhh