karatekid552

Hey there dude! Hope you had a great day!
I'm here to see if you can help me please.
You see, I'm using the G3HS in my hack, and I wonder if you could explain to me how to add the new pokemons at pokedex.

Happy Birthday! Hope its a good one!

Happy birthday!

Just to let you know that I'm still on it, but like I said: I had zero knowledge of ASM (beyond basic comprehension) before getting started with this. I've been swamped with other things, unfortunately, and it will be a while before I'm understanding his source code because I'm having to teach myself some basic ASM first, too. I'm working on it, though. Any tips for good sites, tutorials, etc, beyond what you give in your own tutorial? I've read yours, Hackmew's and Shinyquagsire's, and I've been trying to imprint JPAN's document into my mind as well (that one has been the most helpfull so far, really), but any more tips etc would of course be appreciated.

Actually, from what I've seen, the OP uses slot 1 for his pokemon. Also, I just noticed that some of the battle HUD uses slot 6 as well, just in case that might be important for anything.

The opponent trainer? That uses slot 6.

Ah, I see. Looking closely at the way the game originally loads these sprites/palettes, it seems that it's loading slotting the player into slot 6 during the throwing animation so that it can load the player's pokemon's sprite into slot 0. However, you should be able to use 0 for both, I suppose, as I don't think they are ever on the screen at the same time.

I just spent some time applying JPAN's tool to a clean firered, and inserting my sprites in table, and I got the exact same results: without your fix, the game writes the player's palette to both slot 1 and 6 at the start of battle, so the opponent's palette is glitched. When I do apply the fix from the thread, it does not write the player's palette to slot 6, but this means that the throwing animation will use the opponent's palette, instead. My guess would be that the way JPAN wrote the routine just isn't entirely functional, as it looks like it simply writes to palette 6 too early.

Also, I'm using version 1.1 from this thread: http://www.pokecommunity.com/showthread.php?t=194241

Edit: just to stress it again: the player's palette shows up fine when I do not apply the fix (which means the opponent's palette is screwed up), but the throwing animation doesn't use the proper palette if I do apply the fix.

I'm just curious, what did you use to test your routine with? Because I've tried applying it to my hack again (taking a version before I originally changed this), and it acted exactly the same. However, after some fooling around with the Oam viewer, I've got a clear idea of what is happening in the game when it's trying to load all these sprites:

The unaltered routine has the palette for the first frame of the animation in slot 0, and immediately upon battle start loads the palette of at least the 2nd frame into slot 6, although that frame is not visible yet. However, the game loads the opposing trainer's palette from slot 6 as well; that's why things are going wrong here. I've checked it with the original firered, and that's exactly how it's supposed to go: the game loads the player in slot 0, and the opponent in slot 6. Then the opponent summons his pokemon, which has its palette put into slot 1, and then the animation for the player can use slot 6 (the opponent's sprite has left the screen). However, it seems that in JPAN's original routine the player's animation wrote itself onto slot 6 immediately, so that opponent's palette is overwritten. In your changed routine it does not write itself to slot 6 at all, so that fixes the opponent changing, but because the game is still looking at palette 6 for the throwing animation, the animation will now show up with the wrong palette.

Just to note, the part of the routine that you posted in the thread did show up in the ROM properly, and I replaced the two bytes after that part (which were 0B DF) with C0 46.

Well, I checked it again, but I'm sure I did that right. The weird thing is, I did not have this problem before applying the fix from the thread. So it would seem the table is set up right, at least. To clarify, it's not that the sprite is scrambling the colors in the palette, it's using an entirely different set of colours (while slot 1 still has the proper palette loaded).