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

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.