Battle Background

Looking over the various docs floating around I'm having trouble figuring out how the battle backgrounds are assembled.

The pointers at 0x271850 don't seem to really point to the tile data, at least not in a format I understand. I know there's tile assembly data around too, but at the moment I'm just trying to find the pointers / graphics data for the backgrounds. I can worry about the assembly later.

This info here is probably from one of the documents you've looked at already, so I doubt this will help you but just in case... I mean, it seems to indicate what you might be looking for anyways:

1. 270200 27034F DATA No "Battle Background graphic/data bank selection and palette (3 bytes Graphic Packet, 2 bytes Tile Assembly, 1 byte Palettes), 56 Total" 3/19/2003
2. 270350 27184F PAL No "Battle Background Palettes (168 Palettes, 16 colors each)" 7/16/2002
3. 271850 271A47 PTR No "Pointers to Battle Backgrounds graphics (168 elements, 75 used)" 7/16/2002
4. 271A48 271B27 PTR No Pointers to Battle Background tile assembly (relative to 270200) 7/16/2002
5. 271B28 27ABE6 DATA Yes "Battle Background tile assembly (32x19 tiles (except Ghost Train), 2 bytes per tile)" 7/16/2002
6. 27ABE7 2964FF GFX Yes Battle Backgrounds Graphic Packets (48 packs) + 64 wasted bytes 3/19/2003

Just saying... is there a way to jump exactly to the desired offset from YY-chr?
If i'd detect 27ABE7 2964FF area, then theorically you might be able to create new battle backgrounds, replacing the older ones!

I have a feeling where this might be one of those instances where it's easier just to hardcode the offsets. I'll let you all know how it goes.

On the plus side, finally got a handle on the sprite / town gfx layering. There's a couple parts (stairs in fanatics tower, umm... poles on the bridge in Narshe) where it looks like there's some masking applied, but that's a detail I'm not going to worry about for now.

I have a feeling where this might be one of those instances where it's easier just to hardcode the offsets. I'll let you all know how it goes.

Still that doesn't answer the mysterious question of how they are assembled. Some background parts are reused (like the background town of narshe and Thamasa) so there is surely some code that assemble those. For unique backgrounds, given the tiles are in order, it might just be like normal graphics, but I doubt it.

Well, I've started in on things and got the unarranged tilesets to display and I can say pretty certainly that multiple tilesets are used per background since some of the tilesets are tiny. I assume that's how the same tiles are used for different backgrounds.

I also just realized how the pointers to the tile gfx work, so I'll play around with it more tomorrow or over the weekend.

You can check out the pretty basic tool I made for displaying tilesets here

http://ff3.herokuapp.com/battle

Yep, looks like all that data is correct (unsurprisingly), but I'm still trying to figure some pieces out.

Here's what I've got so far.

6 byte data at 270200:

• The first three bytes (only the first 7 bits of each byte) are the tilesets to use, don't know what the high bit means
• The next two bytes are the two tile assemblies to use. I don't know why there are two
• The last byte I don't know. I assume it's pointer to a palette set somewhere
• The only big anomaly, which unfortunately turns up a lot, is that some of the tileset pointers are set to FF, which isn't a valid tileset. I really don't know how they work, but they're pretty important.

Tile assembly - They are indeed 2 bytes each, I've got abbbbbbbcdxxxxxxa figured out

• a: which of the three tilesets is used, these two bits are added together, so 11 equals 2 not 3
• b: the tile index 1-127
• c: vertical flip
• d: horizontal flip
• x: No idea... yet

Tileset pointers: these are just long pointers, but for right now I'm working on the assumption that everything below bank E7 is uncompressed. It seems to be working, but more testing is needed.

Great findings! Once you figure how to properly assemble them, I'd like to know since I'll need the backgrounds as well for my editor. I could use straight images of the backgrounds but it would be kinda lazy...

Figured out the palettes at least.

From the 6 bytes data at 270200 take the least significant 7 bits of the 6th byte and multiply it by 3. That will give you the starting palette of a 6 palette set from the battle bg palettes.

Individual tiles only use one of three palettes. To get which one take the 3rd and 4th least significant bits from the 2nd byte of the corresponding tile assembly data and subtract 1 from it.

Now I just have to figure out what the hell is happening with those tilesets with an index of FF. I checked out what the code does when it tries to load an FF tileset and... it literally just skips over it (well really it just does a plx and ply then moves on, but I think that's because before that check happens x and y get pushed, so I think it's just undoing what was just done). Maybe I've got to follow the code farther, but I'm pretty stumped for the moment.

---

Okay wow, I did not thing that was going to work, but it did.

So when I said,

but for right now I'm working on the assumption that everything below
bank E7 is uncompressed. It seems to be working, but more testing is
needed

Turns out I was right. However I didn't take it far enough. The uncompressed tilesets are 256 items instead of 128, and a tileset of FF just means to use the second half of the uncompressed tileset (which is apparently always tileset 0). So basically, tileset FF means, tileset[0][tile_index + 128]

http://ff3.herokuapp.com/battle is updated if you want to check out the backgrounds.

http://ff3.herokuapp.com/battle is updated if you want to check out the backgrounds.

Good job! You now just made my life a lot easier.