RHDN Forum Archive - Moving a sprite?

RHDN Forum Archive

Romhacking

ROM Hacking Discussion

Moving a sprite?

Pages: [1]

Author

Topic: Moving a sprite? (Read 2 times)

InVerse
Guest

Moving a sprite?

« on: January 10, 2008, 12:34:42 am »

As you can see, there is a pinball sitting on top of my 'a'. I think it would look rather neat to have said pinball sitting on top of the 'i', instead, in place of the normal dot. Unfortunately, said pinball is not a normal background tile, it is a sprite that sits "in front of" the background tiles. (There were also flippers that were in front of the text, but I just made them transparent since I didn't see any way to make them look good with the English letters.) So... How do I go about moving said pinball?

(For the record, I'll be cleaning up the word 'Pinball' so it doesn't look so rough and I'll likely be redoing 'Family' altogether now that I've discovered that the entire title screen is available (ie, there is a separate entry for each blank space on the screen instead of all those blank lines above the words being rendered by some sort of actually efficient code.))

Ryusui
Guest

Re: Moving a sprite?

« Reply #1 on: January 10, 2008, 12:48:49 am »

OAM is what you're looking for. Find the OAM data for the pinball and figure out where it's coming from.

Nightcrawler
Guest

Re: Moving a sprite?

« Reply #2 on: January 10, 2008, 10:28:15 am »

Ultimately, there's going to be a set of coordinates for the pinball sprite that you'll need to find and change that is loaded into the OAM (sprite memory) table. As for how to find it, check some NES hardware docs and see if you can't track down when it may be written to OAM memory via a debugger.

KingMike
Guest

Re: Moving a sprite?

« Reply #3 on: January 10, 2008, 03:30:27 pm »

Every NES game I've looked at uses one page of memory (often $0200-02FF or $0700-07FF) to hold the data for all 64 sprites (since it's reportedly better to use DMA to transfer sprites than to write to the sprite registers directly).
Unless this is one of the few that doesn't use DMA (unlikely): use FCEUXD SP's debugger, set it to break on writes to CPU address $4014. Scroll up a few lines and you will likely see an LDA. The value loaded is the page number it's using (say x). Then open the bulit-in hex editor, look at CPU RAM $0x00-$0xFF, and look for the tile number (if I remember write, the tile number for each sprite is the second value in each 4-byte entry (so look at $0x01, $0x05, $0x09, $0x0D, etc.) for the tile number of the ball. Then you'd have the RAM address is stored at. The first byte in that 4-byte group is the Y-coordinate (0=top of the screen) and the fourth byte is the x-coordinate. Now reset the game, set a breakpoint for writes to the CPU address of the desired data. When the debug menu comes up, scroll up a bit, and you should see an address it's reading from.
If it's LDA #$xx, then it's a hard-coded value. Note the address of the instruction look for it in the built-in hex editor, then right-click and go to the address in the ROM.
If it's between $8000 and $FFFF, you have a ROM address, then open the hex viewer, scroll to the address, right click and choose to go to that address in the ROM. If the value found is less than $8000, it must be a RAM address, set a breakpoint to that address and repeat the procedure.

Pages: [1]