The 15th Man Project: ASM Thread

Cool. That is helpful info. Thank you for tracking down all those pointers to pointers.

The info I've figured out overlaps with yours a bit, but I can supplement this.

(standing still, facing left)
D8/EA5C: unknown
D8/EA5D: X position of head tile
D8/EA5E: Y position of head tile
D8/EA5F: head tile ID (start of 4-tile block)
D8/EA60: palette and other things; palette uses (0000 1110) bits
D8/EA61: X position of foot tile
D8/EA62: Y position of foot tile
D8/EA63: foot tile ID (start of 4-tile block)
D8/EA64: palette and other things; palette uses (0000 1110) bits

Based on looking at the data you posted, and the data I've been manipulating myself, I'm 99% sure that first "unknown" byte is the number of sprites to load into OAM. N sprites worth of data immediately follow.

Each sprite is a 16x16 tile (on these menus at least), and so the character head and feet make two tiles. That's why all blocks for character sprites begin with 02.

Here's the OAM data for the hand cursor, for instance.

01 80 00 00 3E

It begins with a 01, because there's only one sprite to load in this block of data. (I've also seen a piece of OAM data that just has a zero for the first and only byte, which loads an empty sprite.)

One thing I notice in the data you posted is that all the X and Y values are set to the same value, which is probably a dummy value. Probably another piece of code is responsible for tiling them, and you'll have to find that. So, these tables don't determine the position on the screen. They only determine the palette and the location in VRAM where the graphics are supposed to be. (This is also true of the hand cursor, which is loaded in a dummy position, and then repositioned by other code.)

Also, a note on the palettes. You may or may not be aware of this information, but since it's not in your post:

Palettes:
35 = 0
37 = 1
39 = 2
3B = 3
3D = 4
3F = 5

As you said, the bits 0000 1110 specify a palette from the eight palettes in memory.

The first "digit" of that hex number is 3 in all the cases you listed. This means that none of these sprites will be horizontally or vertically flipped (those are the top two bits 1100 0000), and they will both have maximum priority (they will appear over top of sprites with lower priority -- those are the next two bits 0011 0000).

The second hex "digit" is the one that has the palette, as well as one bit not related to the palette. The palette number in palette memory (CGRAM) is specified by the next three bytes. So, the second hex digit will be the CGRAM palette number, times two, sometimes plus one. In the save/shop/party screens, the character palettes are loaded into palette slots 2-7, rather than their usual slots 0-5 (which would match the character's "palette ID" in ff3usME).

As an aside, there are CGRAM palette slots completely wasted on these menu screens. The cursor doesn't even use its own slot. Instead, it steals four colors from Mog's palette, even though there's at least one free palette available for it on each of these screens.

But anyway, your values up there are pointing to palettes 2-7. Also, all of them have the last bit set (0000 0001), which is related to the location of the sprite's graphics in VRAM.

The main problem I have at the moment is that the Head and Foot tile IDs seem to be unique

The IDs should be unique, because they represent locations in video RAM. The character graphics have been loaded from their ROM location, or possibly from a cache in main memory, by another block of code. These OAM tables don't specify where the graphics are in the ROM, but they do specify where they are in video RAM (or where they are expected to be).

To make this work, you'll also have to track down and edit the code that loads graphics data into VRAM.

Good tutorials are here, if you haven't seen them:
http://wiki.superfamicom.org/snes/show/Sprites
http://wiki.superfamicom.org/snes/show/SNES+Sprites

If you seem to be running out of space in VRAM, keep in mind that the last bit after the palette is basically a part of the name table ID / VRAM sprite address. It's basically the most significant byte of a 9-bit address, indexing an area of VRAM partitioned for sprites. The other 8 bits are in that other byte you labeled "ID". The format of OAM data is weird.

Since all of the characters seem to have that final, after-palette bit set to 1. You can probably find room for more if you set it to 0, accessing the other half of the table. But you'll have to make sure not to overwrite the cursor or anything.

VERY IMPORTANT, LIFE-SAVING INFORMATION FOLLOWS:

I only recently discovered this, and it's made graphics hacking so much easier.

http://www.romhacking.net/forum/index.php?topic=9249.0

It's a SNES emulator with a debug mode that lets you view video ram, palette RAM, OAM, and so on, in real time, as the SNES runs. This is so much easier for graphics-related hacking than Geiger's snes9x debug. I would never have successfully pulled off the menu hacking I've done recently if it wasn't for this.

~~

I also have some info on the weird queue system block C3 uses to insert sprites into OAM, which you'll probably have to work with, and which I've partially figured out.

I started writing about that, but I realized it would be pretty long. I don't know if it's too tangential for this thread. Maybe I'll start a new thread on graphics hacking in the main hacking forum?