[pangenttech]

I'm close to finished with a graphics hack of Mickey Mousecapade.

I need to change how some of the enemy and item sprites are constructed in the last two levels - what tiles they use and where (metasprite construction or OAM). My versions of some enemies are shaped a little differently, animate a little differently, use different tiles etc.

I have been unable, so far, to find the sprite placement data in the ROM. I searched for specific tiles and their palettes and did not find anything obvious in the hex. (Admittedly, the code is hard to read by sight.)

Mesen's Sprite/OAM RAM (in Memory Tools) is outputting valid metasprite data but I haven't yet spotted anything similar in the ROM.

I would be using Shiru's NES Screen Tool to rework the metasprite construction.

It's possible that there's some compression going on or an unusual format, or that the PPU is assembling bits and pieces of the CHR sprite sheets together, in a way that's different than expected, so the rows it's calling are different. It does that for the title screen, which I've already reworked. The emulators Mesen and FCEUX do not account for this, so I can't really be sure.

Maybe the game skips the palette byte, since every character in the game uses a single palette?

These are my notes on what I was looking for in the ROM (one expected tile and its palette)
71 00  Pirate boss
BF 01 Walrus
68 00 Queen boss   (A8 00?)
B6 00 or 02 Cake
A6 ? Diamond
E2, F2 01?? Strange Minnie?

More small questions:

There is a strange version of Minnie in gold on this sprite sheet, with reversed colors. I'm not sure if this actually appears in the game.

https://www.spriters-resource.com/fullview/25909/

The game has a level select cheat, but it seems to mean that you don't get to see the Alice ending. I'm wondering if there's a way to skip to the ending for playtesting purposes.

Also if anyone has experience with ASM 6502 NES coding, I have some additional questions to ask you privately.

[Zynk]

More small questions:

There is a strange version of Minnie in gold on this sprite sheet, with reversed colors. I'm not sure if this actually appears in the game.

https://www.spriters-resource.com/fullview/25909/

That strange Minnie is a statue of her when she gets kidnapped - https://strategywiki.org/wiki/Mickey_Mousecapade/Walkthrough

[bogaabogaa]

I did look at Mini Mouse sprite. That one was copied to RAM before it goes to OAM table from CPU $300-$3FF. When you look at the location in the PRG ROM you will see the copied values blue. This can be refreshed with loading a save state. Like this you can evaluate the Sprite Assembly Data with just observing the blue numbers. The first entire of the blue table does tell how many segment the sprite assembly has. The rest seems to be normal meta data. I do edit this directly in the Mesen debugger. The changes can be saved as a IPS from the Debugger window.



Additional currently used sprites can also be spotted by browsing the current PRG bank. This bank does have free space towards the end. The pointers are just a bit above the assembly data. In the memory viewer you can right click and view as CPU offset. Then you can look up the location of the pointer.

For example at CPU offset $DF71 is the pointer for the Micky Sprite assembly. This two byte are read as little endian. Values d3 e1 -> Offset e1d3.

Good luck

[pangenttech]

That is helpful, thank you.

I'm editing the Queen's construction, which I can now find around 6690/66D0. I should be able to do this now.

It's in a strange (to me) format, made up of three bytes rather than the sets of four bytes that appear in OAM, but the tile numbers are normal (matching what appears in the CHR banks), and so on, so I should be able to edit any assembly I can find. (The palette bytes are usually skipped, which prevents mirroring. There are H and V bytes, then the tile.)

I was, as I said, mainly trying to figure out where the sprites were in the ROM.


Edit: Okay, I'm basically done now.

There may be minor issues.

The sprites for the "playing cards" / dogs get messed up when they turn around, but that's behavior in the coding somewhere.

Submitted version 1.