Patch: allowing use of "reserved" palette colors for player characters

Ahh. I see what happened... you have C9FFD0 in the first line and my brain saw that and immediately passed it off as an address. It was practically invisible to me. If I had looked at it for even 2 seconds I would have realized that wasn't the address I was using and might consider that could possibly be data. That's how I know I've been doing too much hacking recently. Sigh...

Locke is pretty in pink.

The delay is a hair too long to be comfortable, I'm running through ideas for how this could be written in (without having looked at your code yet).

- Actually, we could stop after ANY 12 colors are used at least once, and just assume the remaining ones are unused. This would result in unpredictable behavior in cases where the sprite actually uses more than 12 colors, but it should work if the sprite artist follows the "contract".

This was my original thought. I would imagine if the spriter didn't follow the rules it would act much like the game currently does if it loads a sprite with out-of-bound colors, they end up blanked or with the colors in places where those colors would have been loaded.

That being said, the people applying these patches are expected to follow the rules, just like they are already expected to follow the rules of only using the first 12. I don't see how you are gaining anything by running through the whole sprite sheet. What does your code do in the event it DOES find more than 12 colors? In most cases you are going to find all 12 colors in the first 6-12 8x8 tiles, which would cut down on your loading time by almost half right there.

Correct me if I'm wrong, but the real kicker is essentially rewriting the sprite sheet to use the colors properly shifted. I have two, maybe three, ideas for this, depending on feasibility.

1. Could the palettes possibly be left in place and the unused colors get changed (exactly where they are) to the miscellaneous sprite colors normally at the end of each palette? So instead of rewriting the spritesheets, rewrite the pointer finger, damage/healing numerals, etc... to look for the new color placements instead? This could be tricky with things that change color (like damage and healing) since the colors are on different palettes, which brings me to number 2.

2. Maybe instead of rewriting the spritesheets making a mask for the colors as they are interpretted, as in where it would normally call color 01, now it calls 04 instead, and it apply the mask every time the sprite is refreshed so you don't have to change the whole sheet at once, only the sprites in use. This might not work considering how the bits are placed in the RAM, I don't know how this actually gets applied in the end.

3. Maybe a combination of one and two (assuming both are doable to an extent) to minimize how much is being changed at any given point and to overcome the multiple color problem involved with numerals.

And I will throw in my idea from way back...
4. Load all 16 colors and move the miscellaneous sprite palettes elsewhere entirely. I know hardly anything about the usage of the VRAM so there's likely not 32 bytes floating around that are still free but in the off chance there is, we could get all the colors avaiable... We could potentially make VRAM space by requiring 2 possible monsters to share 1 palette somehow. It could check the palette ID and if they were all different it would force the last two mobs to use the same one or something... I don't know, I'm just brainstorming. I'm way out of my element here.

Anyway. I finally have it working and will try to set aside some time tomorrow to actually look at the disassembly. Thanks again for all your hard work.