Users browsing this thread: 1 Guest(s)
More Character Palettes
I had to wonder, exactly why it wasn't possible to have more npc palettes. Sure plenty have dreamed, better than me have tried, I just wanted to see why.
After some head scratching and debug watching, the game seems to load every overworld character palette every time a character or npc is drawn. Least that's how I saw it work. This being 256 bytes, or, 8 palettes. If you were to load more, you'd have to have a place to put them so, yeah thats a good reason you can't have more than 8 overworld palettes. Least I buy it.
On the other hand, with very carefull planning and creative spriting you still might be able to pull off more than 8 palettes, even with the above limit. By removing the check in the EE bank that forces palette 0-7, you could technically have more palettes.
That doesn't make sense at all though does it? Well, here's the thing, the check is done in 8bit mode. As I said, with careful planning you could assign a value that after going through the normal multiplication, would come out to an offset half way through the normal palette area. What good is that? Well if your sprite was done in a way to use properly the bottom half of one palette and the top half of the next palette, you would technically be using a "new" palette (in the very least a different combination of colors than the normal palette would give you).
As for battle palettes, we know for a fact the game can handle 4 differemt player palettes, so who says those four can't be any four from a list of 255? Or at least one bank worth.
So yes it would take some serious planning, and heavy sprite work but you COULD effectivly have... 11? Or more palette variations for overworld sprites.
Either way more work than I'd be willing or able to do, but I don't see why the idea wouldn't work.
After some head scratching and debug watching, the game seems to load every overworld character palette every time a character or npc is drawn. Least that's how I saw it work. This being 256 bytes, or, 8 palettes. If you were to load more, you'd have to have a place to put them so, yeah thats a good reason you can't have more than 8 overworld palettes. Least I buy it.
On the other hand, with very carefull planning and creative spriting you still might be able to pull off more than 8 palettes, even with the above limit. By removing the check in the EE bank that forces palette 0-7, you could technically have more palettes.
That doesn't make sense at all though does it? Well, here's the thing, the check is done in 8bit mode. As I said, with careful planning you could assign a value that after going through the normal multiplication, would come out to an offset half way through the normal palette area. What good is that? Well if your sprite was done in a way to use properly the bottom half of one palette and the top half of the next palette, you would technically be using a "new" palette (in the very least a different combination of colors than the normal palette would give you).
As for battle palettes, we know for a fact the game can handle 4 differemt player palettes, so who says those four can't be any four from a list of 255? Or at least one bank worth.
So yes it would take some serious planning, and heavy sprite work but you COULD effectivly have... 11? Or more palette variations for overworld sprites.
Either way more work than I'd be willing or able to do, but I don't see why the idea wouldn't work.
The only true wisdom is knowing you know nothing.
you could have any palette you want if you set the npc palette to 6 and utilize an entrance event that changes the object color to XX. This however is not practical obviously but it's a way to do it... maybe if you figure out how this is being done, it could help you out with a workaround of some kind.
We are born, live, die and then do the same thing over again.
Yes, the routine at C0/50EB loads the 32 16 first 8? NPC palettes (200h 100h bytes) in $7300 and $7500. I don't know why exactly there are two copies of the palettes. There's also the C0/158C routine that seems to make a copy of the first 16 8 palettes from $7300 to $7500. There's a lot of stuff going on with the palettes in bank $C0, especially involving $DF and $E0, which are also used in event command that affect the color (of BG, screen and characters). You should try understanding what those RAM values do, I can't just by looking at the disassembly, and also why there is a duplicate of each palette. What you propose is not impossible but require a good understanding of the mechanism involved. Good luck.
Edit: The ROM map list 32 NPC palettes, hence the confusion, but 16 to 31 must be loaded individually since they are rarely use (my theory).
Edit: The ROM map list 32 NPC palettes, hence the confusion, but 16 to 31 must be loaded individually since they are rarely use (my theory).
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.
12-13-2015, 06:36 PM
Well, battle palettes are fairly easy, I think, might have already done it even. But yeah kinda worthless without overworld palettes. And yeah, I still think its gonna take either a total rewrite of the process of loading, or some famcy sort of work around.
Still leaves the issue of planning to ensure you don't have places that require more than it can handle. Then there is also the thing about using a higher number overworld palette makes you moonwalk to the left, not sure what thats about.
Still leaves the issue of planning to ensure you don't have places that require more than it can handle. Then there is also the thing about using a higher number overworld palette makes you moonwalk to the left, not sure what thats about.
The only true wisdom is knowing you know nothing.
12-13-2015, 08:30 PM
(12-13-2015, 07:51 PM)catone Wrote: using a higher number overworld palette makes you moonwalk to the left, not sure what thats about.
Yes it sure does!:
https://www.youtube.com/watch?v=cK6V2Qkoz4A
We are born, live, die and then do the same thing over again.
(12-13-2015, 07:51 PM)catone Wrote: Then there is also the thing about using a higher number overworld palette makes you moonwalk to the left, not sure what thats about.
It's about the code not being made to run properly with high palette indexes in some cases, could be an an overflow of some sort, I have no clue. With proper checks it should not happen.
Seems battle palettes, as far as in battle goes, shouldn't be hard to expand at all, however...
It seems in the area of C3/6E71 is where it loads the palettes for the save/load game screen. Looks like it starts loading from one or two palettes before the normal battle palette 00, then does a CMP 1400.
Seems to me its loading every single palette that may or may not be used during the save screen, then going from there. In other words, getting more battle palettes to load in battle shouldn't be any trouble, but rewriting the save screen (and possibly shops/character select) load palette process would be required as well. This is based off just a little bit of debugging though so, would be nice if I was wrong.
Course may I am wrong to an extent. Still C3/6E71 should be loading hand graphics, yet continues loading palette data to ED/6300 and beyond. Now looking ahead at the next routine run, C3/6CC7, where it should be loading battle palettes (and does use this during battle) it does a CPX #C0 which...
Beats the hell out of me. That's all I can say. Still don't fully grasp that C3/6E71, but now I've got the thing loading palettes from the great beyond like it should be. Least the menu and shop reads them. An hour ago I was loading save games with the white ghost group, now it works. Sometimes it would be nice to know wtf I'm doing. Either way, expanded battle palettes may actually work.
It seems in the area of C3/6E71 is where it loads the palettes for the save/load game screen. Looks like it starts loading from one or two palettes before the normal battle palette 00, then does a CMP 1400.
Seems to me its loading every single palette that may or may not be used during the save screen, then going from there. In other words, getting more battle palettes to load in battle shouldn't be any trouble, but rewriting the save screen (and possibly shops/character select) load palette process would be required as well. This is based off just a little bit of debugging though so, would be nice if I was wrong.
Course may I am wrong to an extent. Still C3/6E71 should be loading hand graphics, yet continues loading palette data to ED/6300 and beyond. Now looking ahead at the next routine run, C3/6CC7, where it should be loading battle palettes (and does use this during battle) it does a CPX #C0 which...
Beats the hell out of me. That's all I can say. Still don't fully grasp that C3/6E71, but now I've got the thing loading palettes from the great beyond like it should be. Least the menu and shop reads them. An hour ago I was loading save games with the white ghost group, now it works. Sometimes it would be nice to know wtf I'm doing. Either way, expanded battle palettes may actually work.
The only true wisdom is knowing you know nothing.
01-02-2016, 12:54 PM
Tis as good a place as any to continue this conversation. While I'm not looking at adding more overworld palettes, at the moment I'm trying to figure something else out about them. This part apso involves FF6LE -- whatever version is it now, I vote it to be called FF6"LExi" version because its so sexy. Maybe I'm off my rocking chair but Level Editor "+" ExHiRom or LE+EX, or LEEX+ (Lexi just flows easier but that just my non-pro theory on the matter. (Have also take into account the last program I wrote from scratch back in about '07 was named "CL.I.T" the "CLothing Inventory Tracker" soooo yeah, while it was fun to finger... the mouse I mean... while fiddling with... needless to say my ability to name something not always the most proper.)
Sprites such as the treasure chest, use overworld palette 17, then we have a puff of smoke on overworld palette 13, and from that sprite up, even higher overworld palettes. Yet with these in mind (info coming from usME) the LE only lets you go to palette 7 on NPC.
So, are they (as Nattak said) using events on palette 6 and eventing it to mimic a higher palette? I haven't checked smoke/fog in Narsh or the talking "Feed me!" Chest in Strago's cave yet, but if LE won't assign higher than 7, and the game flipps if you assign higher than 7... what other options? Other than special cases for every instance. Which still doesn't add up entirely because 8bit palette calculations overflow and bug at 56(dec) and higher. Should be able to load all the overworld palettes (by usME's showing) on a NPC.
Even if we can't get more new overworld palettes, having virtually unlimited battle palettes could work well with 31 overworld palettes (if the moonwalk trick is fixed). Meaning LE needs to lose the 0-7 resriction on palette for starters. Will take a look at it later, been meaning to for a day or two now, see if I can still read, and see what I see. Need to look at something else that I can't figure out on the side as well.
I came across this thought while looking at the "dragon" sprite. Actually looks pretty sweet on some of them high number overworld palettes. (#25 and #21 for instance, with palette #15 still being my favorite.) Something to look into eventually.
Sprites such as the treasure chest, use overworld palette 17, then we have a puff of smoke on overworld palette 13, and from that sprite up, even higher overworld palettes. Yet with these in mind (info coming from usME) the LE only lets you go to palette 7 on NPC.
So, are they (as Nattak said) using events on palette 6 and eventing it to mimic a higher palette? I haven't checked smoke/fog in Narsh or the talking "Feed me!" Chest in Strago's cave yet, but if LE won't assign higher than 7, and the game flipps if you assign higher than 7... what other options? Other than special cases for every instance. Which still doesn't add up entirely because 8bit palette calculations overflow and bug at 56(dec) and higher. Should be able to load all the overworld palettes (by usME's showing) on a NPC.
Even if we can't get more new overworld palettes, having virtually unlimited battle palettes could work well with 31 overworld palettes (if the moonwalk trick is fixed). Meaning LE needs to lose the 0-7 resriction on palette for starters. Will take a look at it later, been meaning to for a day or two now, see if I can still read, and see what I see. Need to look at something else that I can't figure out on the side as well.
I came across this thought while looking at the "dragon" sprite. Actually looks pretty sweet on some of them high number overworld palettes. (#25 and #21 for instance, with palette #15 still being my favorite.) Something to look into eventually.
The only true wisdom is knowing you know nothing.
« Next Oldest | Next Newest »
Users browsing this thread: 1 Guest(s)