GoGoJJTech

Yeah, the only way you could fix the windmills is to have them use a palette 0-A != 2. That is it. Otherwise you will have issues. Your best bet would be a little bit of hex editing and add more tilesets.

Not Dawn's palette slot, her whole OW slot. Just copy her data pointer to a number above 0xD. Also, do the same thing with Lucas.

You are switching OWs, not palettes. THE IMAGES.


and, as I said, the palette glitch with the windmills and such is a physical game freak thing that was there as soon as you expanded the number of ingame palettes.

Dude, why did you design those as OWs??? I mean seriously. Massive objects like that put a HUGE strain on the processor. Tiles would be much more efficient.


Edit:
Also, you really need to learn ASM well.... With this code, you can't use Dawn's OW in that slot. The code works like this:

cmp r0, #0xD
bgt no_change /*Branch if sprite to be loaded is greater than 0xD, or not a player sprite).
cmp r0, #0x7
blt hero_change
sub r0, #0x7
b hero_change

It runs based upon the sprite being loaded, independent of male or female (note the sub r0, #0x7. It is going to use the same loader for both male and female.). So, you are going to run into conflicts when you encounter Dawn. Simple to fix in any case, just copy Dawn's main sprite to a fresh slot and change OWs to work that way. This was an issue in JPAN's hack itself, only mine forces it to be apparent easily. If you had ever tried to use the hero changer, it would have changed Dawn's sprite too. (Note that if you are playing as Dawn, this will affect the male player NPC too.)


Edit 2:
ANNNNNNNNNND I removed my ASM for the OW hack, and those palette errors still happen.

I found that it defaulted to slot 2 because it's palette slot byte was 12, but the slot was just 2. The initial loader will load this correctly, but the one at the start menu won't (the reloader...). So, using 04 as that byte always keeps it in slot 4.

However, even when I get it back in its normal slot, the error still happens.

/me thinks a limiter on the reloader wasn't removed....



Edit 3:
Omg.... I looked at it.... This is ridiculous...


So, now I REALLY know why GF only had 15 palettes....

When the reloader is called, it doesn't cycle through the OWs and load their palettes. No, it goes through and does this:

load palette 0 into slot 0
load palette 1 into slot 1
load palette 3 into slot 2
load palette 4 into slot 3
load palette 5 into slot 4 <- This is the conflict!
load palette 6 into slot 5
load palette 7 into slot 6
load palette 8 into slot 7
load palette 9 into slot 8
load palette A into slot 9



I think if I rewrite my ASM to write the palette every frame, that I may be able to make this code null-in-void.

https://www.dropbox.com/s/4yyi31b5a8ec4ch/bandicam%202013-09-01%2017-37-09-609.avi

You mean that little palette glitch? It only occurs directly after the switch and before a warp.

That doesn't happen to me. Are you using a BIOS file with VBA?

Also, I had to erase your script on the fat guy to test the hero change. Just compile this in XSE to fix it:

I was right, it wasn't aligned. One sec, I'll compile, insert, and send you the rom.

I didn't send it because I had to delete these lines in order to fit it:

lsl r0, #0x18
lsr r0, #0x18

Those are only needed if the table has more than 256 OWs in it, so it was safe to overwrite for testing purposes, but not safe for continued usage.

Just send me the ASM on here. It might just need to be aligned.

I also ran some tests, and adding that line fixes both issues.

After looking at it more and putting it in super slow mo, that is because there is a conflict based on two sprites trying to load in the same slot, at the same time. This is an issue dependent on the issue we had earlier and should go away when you add in the "mov r11, r0" line.

I also see your issue, but you have it backwards. The changed palette is being loaded, but not the sprite...

The only reason you are getting it is because the start menu has a lock command. If we could remove that.....

Or I'll look for a separate sprite loading routine.

I found the main issue, and that is that I forgot the most important line in the whole routine!!!!

Ugghh, this was an after add in so I could make sure we were only editing the hero.

Add this line in(It's in RED):

Hmmmmm. Let me play with it...

Oh, whooops, forgot the +1 on that pointer I added.

Here is the rom: https://www.dropbox.com/s/31iefcjpkdl925n/PLATINUM%20RED%20%28ow%20fix%29.gba

It works now, I was able to test it.

For DC, I just hacked the old routine and added on, I didn't do it this way, which is why this asm had issues. I hadn't tested it before. DC also required extra checks because there is one sprite in particular that I wanted warping to occur in order to change the sprite's size, so I cancelled auto-load for that sprite.

Oh, I didn't know it does that. I already have a Dropbox (actually, that image is uploaded there). Will edit immediately. Thanks for letting me know!

Okay, let's try this again.... Send the rom.

Whoops, my bad, that line for the OW hack should be:

.org 0x8A5AAE4

Then, go to 0x8A5AAE4 in the .bin file.

-_- We already fixed JPAN's hack. That is for the OW hack. Just do what I said, and then go to offset 08A00000 in the .bin. Then you will know why.

I am SUCH an idiot. You know how when you script, you use #Dynamic? Well, I forgot the ASM version of that.

Add this line to the top of your asm file, just below the .thumb:
--

.org 0x08A00000

--