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

I never thought I'd see the day that this kind of patch would be made

I personally want to thank you for this

Thanks for the thanks.

hahaha np

This is an awesome idea... gives me more room for fully custom palettes. I will definitely have to use this once you get the speed thing tweaked. Great job by the way and good luck on perfecting it .

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.

Actually, I did think of one complication: Crusader overwrites the greens at the end of the 4th loaded battle palette. You would need to make sure they write to the colors new locations and that the crusader sprite knows where to read them, which could be a real pain. Still, I would be willing to give up crusader for this.

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.

I had a thought, how about the MP color changing patch? will that affect anything at all?

just curious

The current version should not interfere with the MP color hack. Or the reflect barrier / crusader fix.

If I made the other version I'm talking about (that edits the numerals, rather than the character sprites), it more likely than not WOULD break it, and similar hacks.

Edit: By the way, did you have a chance to test the version I posted tonight? I'm interested in feedback on the speed. I thought the speed was "good enough" even last time. But I was probably being too easy on myself because I'm excited to have a "working" version. And to see progress over how bad it was before. Even I knew it was bad the first time.

The third revision is even better, though.

Edit again:

Oh by the way Poco Loco: your custom sprites are good. I have a bunch of custom sprite sheets saved to my hard drive, along with a list of artist names for credit, ever since I got interested in hacking this game a month or two ago. A lot of the good sprites in my "database" are from you. I've been wanting to use them, and I hope my patch makes it possible to use them with their "real" colors, even in battle. So, you'll be happy to know part of the reason I'm doing this is to use YOUR work. And that of other good pixel artists too. And then make, like, every character a playable character. (Because obviously 14 playable characters is not enough...)

Ok, second go at this. I thought I posted this earlier, but its gone now. Sigh.

Edit: By the way, did you have a chance to test the version I posted tonight? I'm interested in feedback on the speed. I thought the speed was "good enough" even last time. But I was probably being too easy on myself because I'm excited to have a "working" version. And to see progress over how bad it was before. Even I knew it was bad the first time.

The third revision is even better, though.

Now THIS is what I'm talking about. This is 100% acceptable in my mind. And will use this in my hack for sure. However, I need the code placed in another part of the expanded data. Can you maybe make a quick patch with the code moved to F4/E000 (or maybe give me the current addresses that have jumps so I can edit it myself without having to disassemble the code)?

If you dont mind me asking: What is your background? Between this and your post about making long jumps use less space, it's obvious you have a solid history with the SNES. This is more than just good programming sense.

And then make, like, every character a playable character. (Because obviously 14 playable characters is not enough...)

Working on this now, as I see you've already noticed

Since the SRAM is empty after $1E00, we should hypothetically only need to alter how far into the sprite IDs your code looks for sprite sheets to change the total number of sprites this applies to, correct? I say this because as I expand the battle sprite pointers, I may need your code to recognize the new sprites when they appear in battle. Are you using the games battle sprite pointer list when you are checking/writing to sprites?

I'm glad you like my custom characters and finished NPC's I appreciate it

Flattering of you to say about my background. My only background is that I've been obsessing about NES / SNES hardware in order to do rom hacks, for the last few months. I've had time on my hands and I'm the kind of person who tends to get intensely into these sorts of things when I have time on my hands. I've read many documents, and fooled around with code that didn't actually "do anything", but got me used to using ASM for this sort of architecture.

At first I was working on a pretty ambitious ASM-involved hack for FF1 for the NES. I may go back to that eventually. But, before it came to fruition, I got interested in FF6, and the SNES, which has greater abilities but also greater complications (it's a 16 bit version of the same architecture, with a couple dedicated co-processors added). I loved FF1 and FF6 both as a kid, and played them many times, and I got interested in expanding them in core ways, and understanding the hardware in order to do that. Both games are very well documented and previously hacked.

- I'll release a "final" version of the palette hack in the new few days, with some enhancements and refinements.
- I'll make it relocatable in some way or another. It should be easy, at least, for me to find the locations of the few jumps that use absolute addresses. I'll just assemble it for two different starting addresses, and look for the difference. I'll also include the ASM file with the patch when I distribute it.
- I'll make sure it can handle new sprite IDs whenever they're inserted, since I have a feeling a lot of people who want to use it will want to do that. It's almost "what it's for". There should be a fairly easy solution with a lookup table / header / thing, so it can use any random values within 0-255.
- Then I'll only do more revisions if someone finds a bug, or an important incompatibility with another hack.

Is your hack the 15th man project, or do you have another one too?

The palette thing was the first of three or four ambitious / new things I wanted to do if I could. Adding new fully-functional PCs is another.