12-13-2015, 05:10 PM
Oh, I'm not going any farther than I have already. Just based on what it does now, vs what it should do. Way to much code to rewrite for my taste. Not to mention I noticed C0/AA20 makes a call for those palettes yet never saw it run that line. Eitherway, not so much what I was getting at.
These palettes are 32bytes a palette. Starting at E6/8000. Then it takes the character's palette number, in an 8-bit memory, multiplies by 32 to get an offset for that character's palette. Alright, normally it does an AND #07. By removing that, you could feed it a palette number that overflows and gives you something that not a normal offset.
Palette #0 - E6/8000
Palette #1 - E6/8020
Palette #2 - E6/8040
Palette #25 - E6/8010
Palette #36 - E6/8030
Those last two are not exact, didn't do the match to figure what would leave a value of 10(hex) in an 8bit field after being multiplied by 32, but thats the concept. Trick it into loading a palette thst started between two normal palettes, resulting in a mix of two palettes creating a different 15 color palette than the normal.
Granted the planning would be a nightmare, first to figure the proper math to load it, then to make the sprite correct in using it but in theory it should work.
Only other practical option I see is, short of redoing all the scattered code that touches it, would be to head it off just short of loading the sprite (after the normal code) and reorder it there. Pretty much what Nattak said, just via asm instead of event code.
Eitherway, more work than I care to cuss. I still think this idea is crazy enough to work if someone was crazy enough to setup such a thing.
These palettes are 32bytes a palette. Starting at E6/8000. Then it takes the character's palette number, in an 8-bit memory, multiplies by 32 to get an offset for that character's palette. Alright, normally it does an AND #07. By removing that, you could feed it a palette number that overflows and gives you something that not a normal offset.
Palette #0 - E6/8000
Palette #1 - E6/8020
Palette #2 - E6/8040
Palette #25 - E6/8010
Palette #36 - E6/8030
Those last two are not exact, didn't do the match to figure what would leave a value of 10(hex) in an 8bit field after being multiplied by 32, but thats the concept. Trick it into loading a palette thst started between two normal palettes, resulting in a mix of two palettes creating a different 15 color palette than the normal.
Granted the planning would be a nightmare, first to figure the proper math to load it, then to make the sprite correct in using it but in theory it should work.
Only other practical option I see is, short of redoing all the scattered code that touches it, would be to head it off just short of loading the sprite (after the normal code) and reorder it there. Pretty much what Nattak said, just via asm instead of event code.
Eitherway, more work than I care to cuss. I still think this idea is crazy enough to work if someone was crazy enough to setup such a thing.
The only true wisdom is knowing you know nothing.