Jump to content

Editing Palettes with FERecolor


CT075
 Share

Recommended Posts

Editing Palettes using FERecolor

First off, thank Yeti for making this glorious tool. You’re awesome, bro.

Moving on. You’ll need:

  • Your ROM
  • A hex editor, or the Advanced Palette Editor/APE (I use HxD)
  • FERecolor
  • Nightmare, also the “FE_ battle palette reference.nmm” (Or something of the sort)
  • Stills of both the unedited and the edited sprite (They must be the same frame, this is important)

Phew! Now that that’s done with, we can get the meat of this. First off, open up your two images in FERecolor. You should see something like this:

2dc473c5a38474e009bcc3a66562d609.png

Admittedly, the window is kind of big. Possibly, the bottom options are going to be covered by the taskbar. Oh well, get over it and such.

Notice that there’s a bunch of options involving the colors. Don’t touch, since that will mess up… something. Just don’t do it, okay?

Once you have both open, hit “copy hex to clipboard”. A window will popup telling you what the hex is, you can ignore that for now, unless you for some reason know something about this (which I don’t).

8a7866930aac81193c33048f73855c88.png

Do this for both images. Once that’s done with, paste them both in a notepad (or similar) file. At this point, I like to separate the hex for each color with a space. Just for reference, a color is four numbers, like A5B6 or something. Save it as “color list” or some such. Each set of four should line up fairly well, like so:

1e9ca0abdc5cb41bd9799652fcba6643.png

That’s a lot of hex, and it’s going to be difficult to make sense of. Fortunately, you don’t have to.

Before you do anything else, though, you’ll need to find the location of the original palette. This can be found using the “FE_ battle palette reference.nmm”.

8e96f89edee9f5893b4e7ddbd5f19744.png

Next up, open your ROM in your palette editor of choice. I’m going to show both, don’t worry, little children ironic since I’m like one of the youngest people here.

By the way, the offset given to you in Nightmare was a pointer. 0x8blah. So, take off the 8, leaving you with 0xblah (in this case, 0xFDB888).

I think now would be a good time to say that the transparent color in GBAFE is “5553”. This generally corresponds to the first color in your FERecolor list. Pure white (which I used in this example) is “FF7F”.

In APE, first check “compressed palette”, and leave it checked. Unchecking it could really bork it up. Not kidding.

8c36720055bd6b6d95beb0756d1f72df.png

For you APE users, it’s pretty simple after this. You see that color that says, “CB7F”? Well, just go look for that color on your color list. If it’s in both rows, then you can leave it, no problem. If it’s only in one row, look at the color it corresponds to, and replace it. Looks like, for this example, “271F”. So I go to the right spot in the “edited palette” area, and put in “271F”. Rinse and repeat.

fc52d52c6106ab532579d322dd692ee1.png

As you can see, a lot of colors match up, mostly metal and skin tones.

Once that’s over with, just hit “Replace” to save, and you’re done. That was easy.

You guys who are using hex, it gets a little trickier. On the other hand, this is probably just as useful, as it allows you to edit NPC and enemy palettes (as opposed to APE, which only changes player palettes).

If you’re using a hex editor, hit Ctrl-G, and go to the offset that Nightmare indicates.

75895e54e6167228e014433469b1237a.png

The highlighted portion is your palette.

Like before, it’s just a search-and-replace. Just go through the rows, looking at each group. The thing you must remember here, though is that GBAFE palettes are compressed. That means, every four colors (or 8 bytes), there will be a “00” byte.

[spoiler=technical stuffz]

asdlkjfkladsjfkla this part is massively inaccurate and the reason for any and all unreliability (except for failure to follow directions, of course). It would be hard to do better without getting annoyingly technical, which most people wouldn't want to bother with, but it's meaningful and valuable, so I do so below.

Things that are compressed are supposed to be smaller. The 00 bytes are making things longer, so that clearly hasn't happened. These palettes have had the compression algorithm applied to them, but it hasn't worked out so well, because the data just isn't that compressible.

Or is it?

The data that you're seeing is actually a single chunk, from one "10 A0 00 00" word to the next. This is the header for the compression format: 10 indicates the compression format (LZ77), and the rest is the size - in this case, A0 = 160 bytes.

A palette is 32 bytes, so this data-chunk is 5 consecutive palettes. Why 5, I have no idea. But you should keep in mind: there are places in the ROM where single palettes are written uncompressed; there are places with sets of 4 compressed palettes (which I'd think makes more sense in general); and I'm pretty sure there are places where a single palette is compressed (which is mind-bogglingly stupid, because basically no single palettes will actually compress, and it would only save a couple of bytes even if it did).

Anyway, it's entirely possible for a palette to compress slightly if the palette repeats some colours, or more generally repeats a sequence of 3 or more bytes. This is very unlikely, but possible, in the context of an individual palette.

For these groups of palettes, there is actual compression benefit, since e.g. the NPC palette will generally just have 3 or 4 entries changed to switch blue team -> green team, and the rest of the colours will be the same - so there's a chunk of repeated data that can be encoded as such. The encoding could happen to contain something that looks like a colour you want to edit (unlikely but possible), resulting in you editing the wrong thing and wtfpwning your ROM. The part of the data where the new, changed colours are written, could still contain a 00 byte. These aren't "separators" btw, although it might be more convenient to think of them that way; it's an 8 bit value where each 0 bit means "grab a byte of plain data from the following data" (and a 1 bit would indicate "at this point, grab a 2-byte code for compressed data and uncompress it").

cbad6616fa9c29171c44d6655c52cdc4.png

For example.

Don’t touch those. I mean it. It WILL crash your game, unless my luck is just really bad. Just ignore them, and remember to skip them whenever one appears.

For the actual searching-and-replacing, I prefer to just go one color at a time. It’s easier on my brain, which does not have a genius-level IQ and therefore will get headaches from looking at rows and rows of hex.

750bf83a6a17414e18bab36da1d84140.png

The one color you shouldn’t touch

The nice thing about HxD is that it highlights any colors you’ve changed. This is helpful for a myriad of reasons, first and foremost that you can see if you fucked up.

Anyway, if you’re editing NPC or Enemy palettes, then my entire thing about “compressed palettes” flies out the window.

0142c84eeb2e8f541d629cc1ba50b269.png

That’s your NPC/Enemy palette. Edit it the same way you would the normal, except that any 00 bytes are part of a color.

Save, and test. If it didn’t work, try again. I’ve always found writing in direct hex to be the most reliable, but who knows? Whatever floats your boat. I’ve heard that GBAGE is fairly good as well. Either way, I’m out.

UPDATE: Well, thanks to Zahlman bringing up a technical (but semi-important) point to me, there's a technical note in the hex editor section that you might want to read if you're having trouble.

Edited by Kam
Link to comment
Share on other sites

So the main appeals of this method are that it is faster than a method that has been deprecated for awhile, but can let you edit multiple palettes at once in case you wanted to decide on something like a special enemy palette?

And does APE let you edit enemy/NPC palettes? I don't think I've really ever heard of that tool before.

Still think the GBAGE method is faster though.

Link to comment
Share on other sites

So the main appeals of this method are that it is faster than a method that has been deprecated for awhile, but can let you edit multiple palettes at once in case you wanted to decide on something like a special enemy palette?

It's also ~90% reliable (100% with APE unless you fuck something up). And yes, you can edit multiple palettes at once. It's quite literally a search-and-replace, except that now you don't have to spend ~30 seconds per color doing stuff with GBA color picker.

And does APE let you edit enemy/NPC palettes? I don't think I've really ever heard of that tool before.

It might, though I don't know how.

Still think the GBAGE method is faster though.

It very well might be, but this takes maybe two, three minutes. If it's just for a playable character's palette, it takes roughly 70 seconds.

Link to comment
Share on other sites

Still think the GBAGE method is faster though.

There's been programs around for years now that are a lot easier than both. With them you just open your ROM, enter the address of your palette, and it displays the data as a palette sequence, and you can just edit from that, save and be done with it.

Been around for ages .-.

Link to comment
Share on other sites

Yes Celice, because we all have our palette's hex numbers memorized in order like you do, of course.

Thanks for your help.

Naturally, the program is GUI-based. If it didn't have that, you might as well be using a hex editor, n'est-ce pas? Couple this with No$GBA's or VBA's palette viewers and you're pretty fine.

Link to comment
Share on other sites

  • 3 months later...

Like before, it's just a search-and-replace. Just go through the rows, looking at each group. The thing you must remember here, though is that GBAFE palettes are compressed. That means, every four colors (or 8 bytes), there will be a "00" byte.

...

Anyway, if you're editing NPC or Enemy palettes, then my entire thing about "compressed palettes" flies out the window.

asdlkjfkladsjfkla this part is massively inaccurate and the reason for any and all unreliability (except for failure to follow directions, of course). It would be hard to do better without getting annoyingly technical, which most people wouldn't want to bother with, but it's meaningful and valuable, so I do so below.

Things that are compressed are supposed to be smaller. The 00 bytes are making things longer, so that clearly hasn't happened. These palettes have had the compression algorithm applied to them, but it hasn't worked out so well, because the data just isn't that compressible.

Or is it?

The data that you're seeing is actually a single chunk, from one "10 A0 00 00" word to the next. This is the header for the compression format: 10 indicates the compression format (LZ77), and the rest is the size - in this case, A0 = 160 bytes.

A palette is 32 bytes, so this data-chunk is 5 consecutive palettes. Why 5, I have no idea. But you should keep in mind: there are places in the ROM where single palettes are written uncompressed; there are places with sets of 4 compressed palettes (which I'd think makes more sense in general); and I'm pretty sure there are places where a single palette is compressed (which is mind-bogglingly stupid, because basically no single palettes will actually compress, and it would only save a couple of bytes even if it did).

Anyway, it's entirely possible for a palette to compress slightly if the palette repeats some colours, or more generally repeats a sequence of 3 or more bytes. This is very unlikely, but possible, in the context of an individual palette.

For these groups of palettes, there is actual compression benefit, since e.g. the NPC palette will generally just have 3 or 4 entries changed to switch blue team -> green team, and the rest of the colours will be the same - so there's a chunk of repeated data that can be encoded as such. The encoding could happen to contain something that looks like a colour you want to edit (unlikely but possible), resulting in you editing the wrong thing and wtfpwning your ROM. The part of the data where the new, changed colours are written, could still contain a 00 byte. These aren't "separators" btw, although it might be more convenient to think of them that way; it's an 8 bit value where each 0 bit means "grab a byte of plain data from the following data" (and a 1 bit would indicate "at this point, grab a 2-byte code for compressed data and uncompress it").

Edited by zahlman
Link to comment
Share on other sites

You know, technical stuff like that at first sight can be a bummer, but believe me, the more you have patience to read every now or then a technical detail, the easier it is to later to use the system in a way no one has before, and create a better method for hacking. Like using APPs for ways they were never meant to. Like me for example, when I need to extract an uncompressed palette from the game I just use a tile editor to do it, since both a uncompressed palette and a 4bpp tile have the exact same amount of bytes; 0x20.

To be able to better with what you have it is usually useful to know details. Even if you think you will never use them. Because when you start to grow in some different hacking areas you start to notice how those details start to become meaningful stuff.

Not reading GBATek like you would a book, but just paying attention to details of how stuff works every now or then. Seriously, it helps a ton. The difference in between older and newer hackers in level is only because the older hackers had to do many things manually we do in a click, so they know more details like that. Which helps in times of crisis, hence why they tend to be the ones we look for in time of crisis. :)

Great tutorial Kam, I always like to find new techniques to work with palettes. I personally dislike to do palettes a lot, which is weird considering I call myself a graphical hacker mostly. XD For most of my hacks I tend to finish everything and leave palette making for last, this is how my stat sheet making went all along. >___<'

And Zahl, to be honest I find it funny they compressed those palettes regardless; I mean, since they want to just load one of the 4 palettes, for the side the unit is in, they have to first uncompress the palettes in the memory and then pick the palette they want and move it to the rightful place in memory, while if it was uncompressed you could just move it right away. Sure, they must have saved like 200-250 bytes if you think of all palettes saving say 3-5, but at the same time space wasn't an issue in any of the 3 FEs, since all of them have free space to be used(By us. :3). And in FE8's specific case, the fact that mugs are uncompressed in ROM(And I never saw a situation where they get only partially loaded into the memory, so I see little point of keeping them uncompressed) pretty much makes the whole space they gained with those palettes go puff.

So yeah, fun stuff. XD

Edited by Ryrumeli
Link to comment
Share on other sites

And Zahl, to be honest I find it funny they compressed those palettes regardless; I mean, since they want to just load one of the 4 palettes, for the side the unit is in, they have to first uncompress the palettes in the memory and then pick the palette they want and move it to the rightful place in memory, while if it was uncompressed you could just move it right away. Sure, they must have saved like 200-250 bytes if you think of all palettes saving say 3-5, but at the same time space wasn't an issue in any of the 3 FEs, since all of them have free space to be used(By us. :3).

Not to mention that if they did have to try, I've already demonstrated that they could have made the compressed data for the text like 200kb shorter.

Link to comment
Share on other sites

You know, technical stuff like that at first sight can be a bummer, but believe me, the more you have patience to read every now or then a technical detail, the easier it is to later to use the system in a way no one has before, and create a better method for hacking. Like using APPs for ways they were never meant to. Like me for example, when I need to extract an uncompressed palette from the game I just use a tile editor to do it, since both a uncompressed palette and a 4bpp tile have the exact same amount of bytes; 0x20.

To be able to better with what you have it is usually useful to know details. Even if you think you will never use them. Because when you start to grow in some different hacking areas you start to notice how those details start to become meaningful stuff.

Oh, believe me, I find this fascinating (no sarcasm) to read. On the other hand, most people are not me. Which is why I added Zahlman's comment (spoilered) into the tutorial, for people who might be finding problems with my method.

Link to comment
Share on other sites

@Zahl: Yep, it is interesting to see how sometimes "hackers" end up perfecting something that the original programmers didn't, and all while applying the beloved technique called common sense. XD

Can't wait for your system to become more than just a demonstration. ^_^

@Kam: Good thing then, most people tend to be defensive regarding technicalities. Being able to read even if you don't understand all is already a competitive advantage. :)

Oh you did? Nice. ^_^ Albeit I wonder if people will end up having problems with your method, since you explained it pretty well IMHO, it was a good idea. :)

Edited by Ryrumeli
Link to comment
Share on other sites

@Zahl: Yep, it is interesting to see how sometimes "hackers" end up perfecting something that the original programmers didn't, and all while applying the beloved technique called common sense. XD

Honestly, I can't fault the IS programmers too much for the text compression inefficiency. Granted, they massively mis-allocated thinking time to the whole problem of compression, probably because they had too many other things to think about anyway and just said "screw it, just apply the most obvious standard forms of compression to everything". The exact scheme used for text isn't "standard" in the sense of being implemented by an SWI, but I guess they had it lying around from the last several dozen projects.

My scheme is actually fairly complicated: I have variable-length Huffman "symbols" (to pack the "dictionary" efficiently while making things as simple as possible to decode, I store all the one-character symbols consecutively, then all the 2-character symbols, etc., and have a count of the number of symbols of each length), and the symbol dictionary itself is further compressed by using DTE (a fairly simple technique - but not necessarily an obvious one - that (S)NES hackers should be familiar with). The IS scheme uses symbols of a fixed length of 2 bytes - I'm guessing because that's what makes sense for Japanese encoded in something like SJIS where nearly all characters are 2 bytes. But it actually seems to work better for English text than 1-byte symbols - which surprised me, and also gave me a lot of the inspiration for playing around with it. Most of my symbols are complete words, but some heuristics are used to break up long words, look for common prefixes and suffixes, stuff like that. It turns out that splitting punctuation away from words is not always the right thing to do for optimizing this part. And then when I threw in the DTE, it actually meant I had to re-adjust some parameters to get the best results again. It's... not an exact science. :)

I'm hoping it won't be too long until NM3 is at the point where it can be used to edit text and have it automatically compressed with the original scheme. After that, I can start thinking about how to make it automatically use the new scheme ;)

Also, +1 to Kam being a pretty cool guy who edits OPs and doesn't afraid of technical stuff.

Edited by zahlman
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...