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

How I'm working it is:

Esper Terra will load her correct pink palette in battle. It will load from the same memory location it currently does (battle palette #6)

She'll still have to use the placeholder palette when showing up in Esper form out of battle.

Characters who use palettes #6 or #7 for their out-of-battle / map palette will be hard-coded to load the very same palette in-battle. In other words, they'll load from the map palette bank, instead of the battle palette bank. You won't be able to independently edit the two palettes, and it will simply ignore their assigned "battle palette". I don't think using two separate palettes is useful anyway.

So you'll be able to keep Esper Terra with her correct palette and still use the newly enabled ones.

Characters using palette #6 will use the default palette #6 from the world map. If people enable palette #6, it will be up to them to do all the event editing and sprite editing it takes to make it work. It sounds like you have already done some work on that.

I spent some time today tracking down the code that loads the mtek armor in battle, in order to make it show up correctly with an edited palette #7. I think I've gotten this tracked down now. I'll have to do a similar thing with the chocobop spell / slot. For both these cases, I'll either have to juggle the palettes dynamically like I'm doing for PCs, or make them separate sprites on the ROM.

Then I'll have to do some editing of the palette and sprite loading in those three special menus (save / shop / party). I'm not sure how hard that will be, but I already did something similar when fixing the bugs that appeared there with the expanded palettes, so I already half know how to do it.

How it will work is: I'll independently allow users to enable palette 6, or 7, or both, or neither. If you enable one of them, the cursors will change on a couple menus. Probably to be simple white triangles with black outlines, rather than the hand cursor. It should be barely noticeable.

If you enable both at once, you'll have to live with the character portraits eliminated from the menu where you select your party. And some more altered sprites -- the little icons in shops that tell you "this increases your defense" or whatever may also have to be altered to use reduced colors.

In total, this should vastly expand the possibilities available for PC colors.

I want to request a little bit of help from someone.

There are a couple of points in the game where the whole screen turns sepia or grayscale. Flashback sequences, like the one with Terra killing imperial soldiers, and also the ending. I want to see if new colors/palettes appear correctly in those scenes. Does someone have a save state right before at least one of those points?

I also want to test out the Chocobop ability from Setzer's slot. Does anyone happen to know a cheat code that will make him always use that attack, without having to land on the right slot?

There is one at the very beggining of the game, when terra falls in the cave after being chased by the guards.

But I can tell you it will work fine. The way the code works is that its desaturating the color already in place, its not a brand new palette. So all of the colors in the flashback are based off of the colors already set.

Cool. I'll trust that it works for now. At some point I'll probably play through the game at least that far anyway, and then I can verify.

thats awesome, I agree in the sense that all chars had two palette sets is pointless, and I must say you are making things possible that I only fathomed as a pipe dream back in the day

I'm impressed sir

I'm still making the mtek armor sprite in battle work with a custom and/or expanded palette. This has ended up being unreasonably hard for something that wasn't really essential to do. But I'm too invested in it to give up now. I think it's almost done, but I'm still debugging it.

By the way, did anyone notice that you never in the game have mtek armor while you have a full party of four? It's because it steals a palette slot from a PC (along with some video ram). So it can't be displayed correctly unless you have an empty space. Piece of trivia for you -- I never noticed before.

I'm having some trouble thinking about palettes, and the weird multiple ways the game handles them, and how to alter that.

The problem is if I'm going to add over-world palettes 6 and 7 as possible PC palettes, I need there to be at least nine options for battle palettes. That is: the eight overworld palettes (numbered 0-7), plus esper Terra, who on the overworld uses palette 8, and in battle uses battle palette 6, which is a different selection of colors than palettes 6 or 7 for the overworld. Those who have tried to do stuff with palettes know what I'm talking about.

It's not hard to allow selection of palettes beyond the 0-7 range. In the rom, they're stored in a byte, which means they can go up to 256. And, it's not hard to load battle palettes from a larger selection either, since in battle every character gets his own unique copy of his palette anyway, and there's room for four. As long as esper terra is never shown on shops or anything, it's fine.

The biggest concern is ease of editing. I'd rather maintain compatibility with usme and other editors, which only allow you to select battle palette 0-7. I could ask people to hex edit it, or I could write my own custom utility or patching system, but that would be cumbersome, and I'd rather avoid it if I can.

Another possibility is I could always have characters load their overworld palette. It would look it up and retrieve it in battle, shops, and so on, ignoring the existing table(s) in the rom. This means it would have to be set through events, which is a step backwards in terms of ease of editing.

Plus: I can't seem to find the permanent overworld palette in SRAM. Does anyone know where it is?

There are also other solutions where for instance I might only make the map palettes override the battle ones for characters who use o/w palettes 6 or 7. Or Esper Terra might be hard-coded to use her correct palette, and it would not be easily editable. Or I could let you set the battle palette to a dummy value (7 would work), and if it's set to that value, the code would automatically find the overworld palette and load that instead.

And then there's the issue that I'm not even sure all character sprites who appear in battle necessarily have an overworld palette, or whether it's just ones that are associated with a permanent character slot (is that sometimes not true?).

Poco has knowledge about palettes -- I think I learned a lot of what I know from his documents. His thread was recently bumped, but I can't find some of the information I want in it (namely the SRAM locations).

The ideal solution would allow me to simplify palettes, or at least not make them more complicated. It would be nice if every screen could load the same palette automatically, and if this could be set in the ROM, rather than through events. Maybe I could maintain the ability to override the palette through events, in case someone wants to change a PC palette through events (without changing the sprite).

But I can't figure out how to do this without compromising other things, like ease of editing with existing editors.

Any help with these issues, or feedback on what solution would be preferable, would be appreciated.

4 magitek armors CAN be loaded in battle and although all the characters themselves appear fine, there is an extra weird glitchy magitek armor in the battle, some formations using too many different palettes load the same glitch

I'm not sure which these formations are though

I did have the SRAM locations but I lost them when I lost my storage device so sorry about that =/

Here's some progress I'm making.



This is a picture of the kind of glitch I was experiencing, which led me to look at the menu screens I'm looking at, and try to put some "finishing touches" on things. It's turned into a bigger project than that, obviously.

Mog's and Umaro's sprites were wrong on several screens, because their palette was partially overwritten by the hand cursor (yes, just like in battle). This was sort of dumb, because there was free space for at least one more palette on each of these screens. Then again, there was also no disadvantage to it, given that they weren't going to use beyond the first 12 colors anyway, for other reasons.

The sepia/bronze palette used on the save screen was also glitched with expanded-color characters. In a similar way, for similar reasons.

Well, here's the progress I've made. The party-change screen (seen above with Mog) is still not fixed. But will be.

Here is the save screen.



Shadow is not glitched here. He is using palette 6, and showing up "correctly", albeit with a weird palette not designed for human characters.

Black Celes is also using a previously-unused palette: number 7. In the unaltered game, palettes 6 and 7 would show up with random colors on the save screen. Now, not only do the expanded colors of palettes 0-5 all show up correctly on the save screen, but so do palettes 6 & 7.

This is not an unaltered palette 7. It uses the exact same set of colors as before, but they have been switched around, so it will look better when it's assigned to a PC. I also played with the chocobo and magitek sprites to compensate for that (they are the only sprites that originally used it) and so they look the same as before. Just editing the sprites (shuffling the color indices) worked for the world map, but in order to get it to work in battle too, I also had to alter the way the mtek graphics are loaded for battle. The sprite now caches itself in RAM the same way PCs do. That allows me to do the same expanded palette thing I do for PCs. So, it looks right in battle too, now.



This is the "secretly impressive" screen shot. The impressive part isn't the PCs using expanded colors (which you've seen before), but the part the shows no sign of being altered: the mtek armor. It's using expanded colors like the PCs, except that its expanded colors are the same colors, moved to different indices in the palette. This unreasonably was hard to do compared with the payoff. But it's done.

So I've done the save screen, and I'll do the party-select and shop screens too. You might remember me talking about tradeoffs, like the cursors being simplified or face portraits removed. I won't have to do this, because I've gotten clever. All eight palettes can be enabled without any disadvantages, and can all show up on the same screen, AND there can be additional elements like cursors and portraits that have their own sets of colors too.

"How is this possible? Isn't the palette space on the SNES very limited, and isn't that the reason for this patch in the first place?"

Yes, it is. But there are tricks to get around it, including one called HDMA. It turns out, the SNES can write to video memory during short breaks between TV scan lines (V-Blank). Thus it can alter itself as the picture is progressively drawn on the screen, starting at the top and moving down. This is already used in the vanilla game, to make the gradient effect without wasting tons of palette indices on it.

I'm using this to change the palettes mid-way through drawing the screen.

The save screens you're looking at actually have 12 different palettes visible at a time, per screen. Each character can have his own, and they can all (in principle) be different. There are different versions of the sepia/bronze palette for each original palette, unlike in the original game. My version looks better than the vanilla game.

They could also be shown in full color if I wanted. And they will be on the shop and party screens.

There are limits to how much data you can transfer over time as the picture is drawn down the screen, within a frame. You can't change every palette all at once on a single scan line. You have to work it out carefully. So, this technique works because these screens are very ordered, with all sprites holding still in a predictable place.

In other words, don't ask me to pull something like this off in the battle or town screens.

Well, OK. I hope someone enjoys making full use of the full set of palettes once this is done.

4 magitek armors CAN be loaded in battle and although all the characters themselves appear fine, there is an extra weird glitchy magitek armor in the battle, some formations using too many different palettes load the same glitch

Thanks. I might look into this eventually, but not right away. My version should glitch the same way as the original, but not be any worse.

Oh, and BTW, the world-map PC palettes (the ones set by events) are in $1f70. That would be RAM. In the .srm file, it's the corresponding place, which is +970 offset from the beginning of the save slot. They're "doubled". It's their palette number (as seen in ff3usME) times two. So there's that information, if anyone else wants it.

This is seriously fantastic. I await the finished product. You should totally call this patch PaletteJack, which I was going to use if I ever got around to a 16-color patch. My solitary contribution. I was skeptical about using palettes 6-7 because I didn't like the idea of a tradeoff because I'm more than happy using the existing palette space, but if you removed even that tradeoff, this is just amazing-good.

Will this add any additional lag in any additional places? I imagine you are recoloring the mtek armors in the actual ROM so that it doesn't cause additional slowdown. And for the save menu, since you are altering palettes in the time it takes to write the screen that probably isn't causing any noticeable slowdown. But anything else? Is there ANY drawback to ANYTHING you are doing? Cause you are seriously kicking Square's butt right now in coding.

Yes, it is. But there are tricks to get around it, including one called HDMA. It turns out, the SNES can write to video memory during short breaks between TV scan lines (V-Blank). Thus it can alter itself as the picture is progressively drawn on the screen, starting at the top and moving down. This is already used in the vanilla game, to make the gradient effect without wasting tons of palette indices on it.

I had actually heard of this and thought of using it a while ago, but since it had to do with the SNES graphical processing, I wouldn't touch it with a 10-foot-poll (which would make hacking a lot harder). I am seriously impressed.

PaletteJack

That went over my head for a minute. But it has to do with the kind of palette that you use to lift crates, right? And the thing that lifts them is a jack? Nice. I do like puns.

Will this add any additional lag in any additional places?

On the map screens, there should be no additional lag of any kind, since as you said it's just reading an altered graphic from the ROM.

In battle, since the mtek armor is enabled for expanded colors, it induces lag similar to a PC. As with a PC, it is longer the first time the sprite sheet is loaded. After that, it is shorter, because data is cached.

The way to avoid this (and still juggle palette 7 to make it better for PCs) would be just to store two versions of the mtek sprite and the palette in the ROM: the map one, and the battle one, which would have its original pre-juggled sprite and palette.

The only reason I didn't do this fairly simple solution was because I didn't want people to get confused if they edit the mtek sprite or palette and it only changes on the map and remains the same in battle. But, this is why I said the effort I put in was unreasonable for the payoff. I just wanted to do it once I'd started it, to "beat" it or something. You can easily circumvent my new code if the short load time bothers you, by changing a couple pointers in the patch/ROM.

As for windows: there should not be any lag on the windows because of the HDMA or extra palettes. These windows don't really have much to do besides HDMA, so they are fine.

All 8 channels of HDMA are normally enabled for the battle and town screens, which are much busier. (And they consume cycles each h-blank even if they aren't doing anything, which they often aren't. But not too many.) HDMA is normally not used for switching palettes, but for other graphical effects. It helps facilitate transparency, "bendy" effects like those that create heat distortion, and so on.

The menu screens I'm working on had unused HDMA channels, and the SNES can handle it quite well.

So basically, there is no downside.

I had actually heard of this and thought of using it a while ago, but since it had to do with the SNES graphical processing, I wouldn't touch it with a 10-foot-poll (which would make hacking a lot harder).

Which reminded me: you asked me before if I had background, and I realized I actually do. Although not in the SNES or any game system. I've done stuff for research on perception / vision (perceptual psychology). This can be surprisingly technical if you specialize in the technical side of it. It involves very precise calibration of equipment and writing of your own programs, so you can (for instance) do an experiment that involves demonstrating that people can perceive a certain kind of stimulus that is visible for exactly 1 tenth of a second, or something like that. And it better not be off by a hundredth of second.

In fact, I even did experiments specifically about color perception, making it even more like this.

So, to make these programs and hardware work correctly you have to know all about this stuff: h-blanks and v-blanks and palettes and so on. And it can actually be very easy to mess up if you don't know what you're doing and rely on other peoples hardware or programs, which aren't designed for precise timing or precise calibration of color, or which you don't understand. I was often in charge of doing this hardware/software stuff.

So, just to make other rom hackers feel better about my amazing graphic-hacking skills (not to mention Square's original programmers), I actually did make a living doing something like this. (For some reason the connection didn't immediately occur to me.)

Anyway, that's enough trivia/biography about me.