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

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.

The latest code has already done most of the efficiency things I talked about, and more. (You should have seen the load time before. It was atrocious.)

I think I've gotten close to optimal on my newest revision (posted in a reply). It's heavily commented, so you can read it. But basically, I transposed the original loop. Meaning: there used to be an outer loop through bytes of graphics data, and an inner loop through colors. Now the outer look is through colors, and it stops as soon as it finds an instance of a color, and looks for the next color from the start of graphics data.

It checks the expanded colors first (the last four, "unusable" ones). I judged this to be probably more efficient on average. Many original sprites do use less than 12 colors, so even in the case of an unaltered sprite, you sometimes end up looping through all the data once or more. For sprites that do use the expanded colors, it's usually more efficient to check those first.

It also keeps track of how many expanded colors are found (which need to be switched in), and it only looks for that number of normal colors to replace. It stops after it's found enough unused colors that can be replaced.

I don't think it's doing too much superfluous reading, bit it still takes time, because there are so many bytes.

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.

Writing the sprite sheet is probably less than half the total execution time. Though I haven't rigorously clocked it, I expect reading takes longer.

If you want an intuitive benchmark of this, load a save game where you have all characters in your party. Then use a party of only "expanded palette" characters (characters that use the last 4 colors), and compare with a party of only characters with unchanged sprites. The expanded palette characters will take longer to load, but the unaltered sprites (using only the first 12 palette entries) will take pretty long too. That's because it still has to read enough sprite data to determine that those sprites don't use the expanded palette. It doesn't need to write anything, and it skips that part of the code entirely. But, it still takes time.

Writing RAM is pretty fast, and the write process only has to loop through the graphics data AT MOST four times. At maximum, it has to replace four unused "normal" colors with four "expanded" colors from palette entries 13-16. Often fewer than that.

The reading code, on the other hand, always has to loop through the whole $2000 bytes AT LEAST four times, to determine that the last four "expanded" palette entries are unused (if they are). That is the best case. If any of those entries are used, it then has to find a corresponding number of unused entries from the earlier palette numbers, which means looping through the whole thing again, at least once for each replacement color, plus the partial traversals to find that used colors are used.

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.

This is such a good idea. I wish I'd thought of it. It might be a little finicky to get working with the different palettes and so on, but I don't think it should be impossible.

I know that most of these graphics (the numerals and so on) are compressed. I remember reading somewhere where they are, but I can't seem to find the information. Anyone have it?

But anyway, I can't think of any fundamental reason this idea won't work. And it should cut down on the writing time drastically. The only downside I can think of is that I'll need to find a few bytes of unused RAM to store which palette indices are unused. The number of bytes needed to replace, though, should be drastically fewer.

The only reason this isn't a total solution is that, like I said, reading probably takes longer than writing.

I earlier proposed that we could cache the data on palette entries that are used/unused. If I implement that cache, and also cut down on writing time as per your suggestion, it should make the algorithm almost instantaneous, except for the first time a sprite is loaded.

The other idea would be to store the altered graphics in the ROM, like I suggested before. This would of course fix it entirely, at the cost of having to alter the ROM.