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

New version, with cache. Much faster.

http://bitshare.com/files/bdmjaqss/expan...01.7z.html

For original sprites who only use colors 1-12, "load time" (graphics processing time) is now nothing basically. For ones with expanded colors, it is much improved from before. In a battle with all four character having "expanded color" sprites, the screen tends to come in from black on the beginning of the second measure of the music. (The usual time is the beginning of the first measure.)

That is, of course, subsequent to the initial reading of the sprite sheet, done the first time the sprite is used in battle. The palette-usage data is then saved permanently for that particular character, cutting down on image processing time in the future. The initial time takes a little longer, but even then it is not that bad, and it only has to happen once.

The cache is in SRAM.

No, not the section of working RAM where data is kept that is going to be stored to SRAM when you save your game. (I was thinking of using one of the small sections of unused bits there, but didn't want to make my patch incompatible with other ones that also use those bits.)

I'm actually saving to a location in actual SRAM. One which does not belong to any of the three save files, and is (as far as I can tell) never used.

A small amount of data is already saved in SRAM outside of the individual save files. I think I heard it has something to do with randomizing monsters on the veldt. The bytes I'm using are not in the same place as those bytes and shouldn't interfere.

I don't think there should be any problem with using SRAM this way. If someone can tell me one, though, or if testing seems to reveal one, let me know.

Now, using SRAM has built in positive side-effects: the cache is retained even when the emulator/system is turned off, though it's independent of a particular save-game. As long as your emulator/system saves a srm file, you'll only need to do the longer graphics "load" once.

There is an annoyance for rom hackers / sprite developers. If you edit your sprites, such that they now use a different subset of the palette, and you already have data in your SRAM, the obsolete data will be loaded, and your graphics will be messed up. Of note: SRAM is also a part of the save state in most emulators by default.

The data will be recalculated from scratch and refreshed if you delete your sram file, or if you keep a srm or save state where no data has been cached yet, or if you edit your srm file and just zero the bytes that hold the cache. Those bytes are found at 1E00, which is just after the end of the third save file. When there is pre-cached data for all 16 battle sprites, the cache takes up 32 bytes.

Todo for final version:
- It should calculate and store all the data the first time you start a new game. Then it never has to be done again.
- There should be a more convenient way for artists/developers to refresh the data to update their sprites. Something built into the rom, like a combination of buttons you can press while in the menu or something.



So, now I'm wondering, is it worth it to do the other thing we were talking about, namely changing the hand cursor and so on instead of the character sprites.

As far as I know, the sprites that need the "extra" palette slots are the cursors, the damage digits, the floating things related to status effects (like the spinny thing for confusion, and the bubbles for poision), and crusader. I'm not sure if that is all of them or if there are more.

I'm afraid it might be annoying to search all of these instances down. After finding where they're loaded, I'd then have to insert code to get them all dynamically edited whenever they're loaded, and switch their pixels around in a different way each time, depending on who's in the party at the time and which palette entries their sprite sheet uses.

In fact, I might have to do something even more convoluted: make multiple versions of each sprite, or change them many times per battle. Because, if the palette entries are all mixed up, then switching text from white to green (for instance) doesn't just mean switching to the other palette. It means remaking the sprite, so its pixels use the right parts of the other palette. That might end up being a mild to moderate headache in practice.

This dynamic sprite editing would be quick each time for the CPU, since those sprites are much smaller than the character sprite sheets (except for Crusader) If I did it, it would probably make the patch basically seamless, with no noticeable delay ever.

There would, on the other hand, be a tedious delay on my part as developer, researching and coding it. And hopefully I don't end up causing any strange, intractable bugs.

Does it run fast enough as it is? If so, the other thing might not be worth doing.