[Spriteiscoolio]

I'll try to explain my problem as well as I can. I've already received some suggestions on the IRC channel but I'm coming here for any extra help I can get.

My problem is that in the game I'm trying to edit, I'm trying to make it in the vein on old school RPGs where an icon appears before a skill or item, like so. Here's what it looks like on this particular screen.



I've made white magic icons. Looks kinda nice in my opinion. My problem is...



This happens whenever I go to the skill menu. The grey color of the icon turns completely black.. I'm thinking that it's the fact that the palette doesn't include that grey color. But how do I add it in? I've been suggested corruption tools but I'm not sure how to work them. Sorry if this is totally obvious. I feel like I'm being completely impatient and looking for an easy way out, but I'm willing to try anything and learn how to fix this.

[Ryusui]

As a first step, try running the game in B/W Game Boy mode (most GB emulators should have a toggle for this somewhere in their settings). If the icon still appears solid black, then the problem has something to do with how the game copies the tiles to VRAM for that particular print routine - it might be copying the same byte twice instead of properly copying both bytes of the tile. This'll take some ASM hacking to fix, but it shouldn't be difficult.

If it shows up properly, then yes, it's a palette issue. I don't know much about GB palettes, but the general idea should be simple: find the appropriate palette in memory, set a write breakpoint to its location, then when the game breaks (pauses on the write), trace the code and figure out where the palette data is coming from.

[Spriteiscoolio]

As a first step, try running the game in B/W Game Boy mode (most GB emulators should have a toggle for this somewhere in their settings). If the icon still appears solid black, then the problem has something to do with how the game copies the tiles to VRAM for that particular print routine - it might be copying the same byte twice instead of properly copying both bytes of the tile. This'll take some ASM hacking to fix, but it shouldn't be difficult.

I should have specified it's a Game Boy Color game...that might make things different. All of the methods I've tried however still end up with the icon appearing black.

[Ryusui]

GBC-exclusive, or GBC-compatible? There's a difference. Run the game in GB-only mode and see if the game runs, or if you get an error message.

[Spriteiscoolio]

GBC-exclusive, or GBC-compatible? There's a difference. Run the game in GB-only mode and see if the game runs, or if you get an error message.

GBC exclusive. I get an error message that says "This game can only be played on a Game Boy Color".

[Ryusui]

Right, then. BGB's debugger has a palette viewer. That'd be a good place to start. I'm assuming that your icons display as BG tiles rather than OBJ sprites, correct?

[Spriteiscoolio]

Yes, they are. I'm actually taking the easy way out and overwriting font graphics to make icons easier to implement.

[Ryusui]

Good, good. Like I said, use BGB and its debugger's VRAM viewer to check which BG palette the offending tiles use. Then check the palette data and see what colors are actually in the palette. (The left column is the BG palettes, numbered from 0; BG 7 is the one on the bottom.)

[Spriteiscoolio]

I get it! This makes pinpointing the colors a lot easier. The palette my game is using for the icons is BG0, and the colors are 7FFF and three 0000s.

Now, how would I use this new found knowledge to pinpoint it in a palette editor like SNESPal? I've looked around on google and some sources have told me to enter it the RGB values into a hex editor, but I think I'm missing the point.

Thank you very much for all your help so far as well.

[Ryusui]

The obvious way, of course, would be to simply hex search the ROM for that sequence of palette bytes - it might be 7F FF 00 00 00 00 00 00, or it might be FF 7F 00 00 00 00 00 00 if the palette values are stored in little-endian format (probably this, but it pays to try both ways). Otherwise, you'll have to catch the game in the act of updating the palette. Is BG0 ever not White-Black-Black-Black?

[Spriteiscoolio]

The obvious way, of course, would be to simply hex search the ROM for that sequence of palette bytes - it might be 7F FF 00 00 00 00 00 00, or it might be FF 7F 00 00 00 00 00 00 if the palette values are stored in little-endian format (probably this, but it pays to try both ways). Otherwise, you'll have to catch the game in the act of updating the palette. Is BG0 ever not White-Black-Black-Black?

I wasn't able to find anything with that byte string (It still selected something but it wasn't the exact string I put in. Is this normal? Should I continue from here? It has 84 instances of this same string no matter what I put in. I'm not sure how to input it either - 32 bit float? 64 bit unsigned? I really don't even get what I'm supposed to preform my search terms with) but yes, the BG0 does change. It's usually something like

In game menu: 7FFF 0000 0000 0000
Overworld/Towns: 7FFF 0000 00EF 027B
Dungeons: 7FFF 0000 00AD 1279
Title Screen: 7FFF 0000 56B5 7FFF

Or is that not what you meant

[Ryusui]

That's exactly what I meant. :3

So we can catch the game in the act of loading the menu-specific palette and change it to whatever we like. In theory.

I'm doing my research, but I find the process of writing to palette RAM inscrutable, to say the least. If you can find the palette data in the ROM itself, then that's super: we just change it and call it a day. In the meantime, I'll see if I can't figure out how we can find its location with an ASM trace.

EDIT: 64-bit unsigned should give you the best results. 64 bits = 8 bytes, and unsigned means it takes all the bits as literal numeric value rather than interpreting the highest bit as a sign (if it's 1, then the number is treated as negative). And since this is technically an integer value, definitely don't have it look for a float.

[Spriteiscoolio]

All right, now I know a little bit more on how to search on this, so I'll try my hand and see what I can find. I'm not sure if I'll actually be able to find the palette data, but it's better me to try than to not if you ask me. Hmm...I'm actually not getting that fantastic of results. I'm still not sure what to start searching for.

I wish I could be a better help...I'm just not experienced with these tools and how to use them properly yet.

[Ryusui]

Okay. It's taken me some effort, but I've figured out what you need to look for.

Palette data is written to palette RAM using the registers FF68, FF69, FF6A and FF6B. Registers are special memory values that allow the game software to access certain hardware functions - controller input, for instance.

In this case, we're primarily interested in FF69, which writes data to the BG palette RAM. Run the game in BGB, wait until just before the game loads the menu palette, and then use "access breakpoints" under the Debug menu in the debugger to set a write breakpoint for FF69 (type FF69 in the "addr range" field, make sure "on write" is checked and "on read" is unchecked, and click "Add"). This should catch the game in the act of writing the menu palette to palette RAM. Now we can find out where the palette data is coming from: hopefully, it'll be somewhere in the ROM (addresses 0000-7FFF), but if not, look at the RAM address indicated and see if you can find it there. We can then repeat the process, only this time, we'll set a write breakpoint for the RAM location of the palette in order to find out where it's coming from.

[Spriteiscoolio]

All right, I got it. And I did it twice just to make sure I did it right. This is what I got out of it. Is this what we're looking for?

[Ryusui]

Dandy. And I've got some good news for you! It looks like the palette data is stored in the ROM!

I'm assuming this sequence repeats itself at least once:

Code: [Select]

inc de
ld a,(de)
ld (ff00+69),a
In English:

1. Increment (add 1 to) the two-byte register value "de". This is the address for reading palette data from the ROM.
2. Load 1 byte of the palette data from the ROM at the address stored in "de" (in this case, 7F22) into the register value "a".
3. Load register FF69 with the value stored in "a".

Are you following?

See the ROM viewer at the bottom? We need to know which bank it's looking for palette data in. Once we know that, we can calculate the file address. Scroll down to 7F22 and note the number after "ROM" on the left. That tells us the bank. Just to be sure, look to see if "7F FF" or "FF 7F" is at or near that address, followed by a string of zeroes. That's the palette data we're trying to edit. Got it? Good. We're almost done. :3

[Spriteiscoolio]

Holy crap, I'm actually taking this in and understanding it. Well, getting a better grasp of the methods of palette editing, that is Is this what you meant?

[Ryusui]

Direct hit. Now, if my math is correct, you should find that data in the ROM at 83F22.

Try changing the zeroes after that FF 7F - just random values will do - and see if the palette changes next time you run the game. If the colors are different, then we've found the palette data. Now we need to change it.

Find the palette the game uses for the menu tiles where the icons display properly and use that. Remember, the values are little-endian - the second byte goes first. For example, if you wanted to replace the palette with this one you mentioned earlier:

Title Screen: 7FFF 0000 56B5 7FFF

You'd change "FF 7F 00 00 00 00 00 00" to "FF 7F 00 00 B5 56 FF 7F".

[Spriteiscoolio]

Well, something happened...the palette is FUBAR. I used the title screen values. But at least now we know we can edit it more directly, right?

[Ryusui]

Peculiar...and slightly alarming. Are all the palettes like this now?