The problem I'm having seems simple enough, but I could use a conceptual explanation of how to accomplish my goal (like NC says, concepts help A LOT).

The issue:

I'm translating some menu names which are displayed as sprites. The problem is that they are displayed as one or two letter pieces, and some of these pieces are reused (see images).



(Ignore the other garbled text, that's me trying to change something else, the problem there is that the tilemaps are compressed. I've isolated the compressions routine but I haven't deciphered it yet.)

Alright, so I've tried some debugging and finding how it stores what pieces are used where, but I couldn't really find anything. There's plenty of space to store the extra graphics, so I just need to modify where it loads each piece from and what pieces are used (along with X/Y coordinates). Any suggestions?

So, what am I looking at in the screenshots? I'm assuming, the part you're talking about is the 'EM' that you changed in the first screenshot and it shows up on the second screenshot which you expected to still be in all Japanese. Is that right?

I'm trusting your ability level that the text is indeed sprites which would mean they're stored in a sprite table with x/y pixel specific coordinates which is what it seems like from your post.

Sprites don't have to be the same size. I'm not sure what sizes GBA offers, but it's more than just one. So it could be perfectly normal that one sprite may be the size of one letter and another may be the size of two. Sprite size information should also be in the sprite table.

As for why a sprite appears to be used in more than one place, it's the same concept as reused tiles. You have your sprite table that can keep track of a bunch of sprites. Well, for each sprite, it points to somewhere in VRAM that contains the graphical data to be used for that sprite. It just so happens, you can set it up so say ALL the sprites use the SAME graphic.

So, you could set up the sprite table to display say 64 'EM' sprites all over the screen. It would take up no more VRAM space than just storing 'EM' ONCE.

It's just like tiles and a tilemap really. No difference other than the sprite table is more complex because it contains  more information than a tilemap and you can do more with sprites.

So, the hack is going to be along the same lines as if it were tiles. It's two fold. First, you need to make sure all the graphical data is loaded. Second, you'll need to make sure the correct sprites in the sprite table point to(or are set to use) the graphical data you want them to.



The first thing you can do before jumping in head first is to learn a bit about the GBA sprite table if you haven't already and see if my assessment is correct. You'll know this by looking up data for the 'EM' sprites that are used in the two screens. If I was correct, you'll find they both point to via index the same spot in VRAM thus using the same data, but still being two different sprites.

DMA doesn't alter the data, so yes, it should be in ROM exactly like it appears in RAM, unless it wasn't DMA'd but uncompressed or sth. But I guess they wouldn't compress single tiles, pretty pointless.

That's usually it. Most gba games use a sprite-builder type of thing. Instead of having each and every x/y value and palette defined for the whole sprite, they just generate sprites in wram and then dma to oam. When I look at your screens, you probably didn't resize the sprite for "I" (in ITEMS), did you? If so, your spritebuilder probably takes into account the width information for each letter. So you might want to either set a breakpoint in the width table (if the game has that...) or look for when certain registers contain 0x08 or 0x10. No$GBA offers that function. On the other hand, you can totally dismiss all this and trace back from the dma source. Say, you load the screen the first time and catch where it dma'd from. Then you exit and set a breakpoint to that wram location. No you enter the screen again and should also be somewhere in the code for building these sprites. Then you can figure out what it loads when and how and where from

cYa,

Tauwasser

It looks like what Tauwasser said is right, it creates all the sprites in RAM and then DMAs them all into OAM. I found the chunk of code that sets up each sprite in the RAM, but what I'm having trouble finding is where it sets up the registers that that routine takes. It seems to do all the sprites at once, in a loop. Multiple places load the values into place, most likely because the some sprites are the same sizes. I think my problem is not knowing enough debugging theory. I'll check the documents again, but any recommendations?

Thanks guys! After around another 2 hours of debugging I finally found where one part of the data was stored and led to the rest of it! The strange thing was that the two pieces of data that represent the size and shape of the sprites and the x-coordinate, where ORed together, and the size/shape were stored as an index of what I call "canned" sizes, a list generated when the game is loaded. So it was pretty crazy, but I finally found out how the data is stored, I'll post screenshots when I put in the new titles.