Punch-out graphics hacking help

Hello all,

This is my first post on here, so forgive my immediate request.

Recently, I decided I wanted to edit the graphics for the NES version of Punch-Out! This is the first time I have ever done any ROM editing of any kind. I started this a few days ago, and actually feel like I have learned a fair amount. However, part of what I have learned is that, perhaps many common graphics hacking techniques are not as easy in this game. Here are some thoughts/issues/observations/things I've learned:

- I believe I get the whole concept of editing tiles/sprites. I've tried some of the common tools (YY-CHR, TLP, and some others), and none quite seem to do everything I would like. I like the tile arranger aspect of TLP, as well as the ease with which I can import BMP's. I like that you can change the sprite arrangement (FC/NES x16 is a LITTLE better) in YY-CHR.

- I realize many of the graphics here are displayed in the "background", such as Little Mac himself.

- I am aware that in FCEUX, you typically can use table mapping to learn where each tile is in the ROM, though i cannot seem to get any of the OBJ sprites to actually appear, no matter what scanline setting I use.

So, what I am hoping to learn is, what is the best way to go about this? i very slowly, painstakingly, edited two versions of Bald Bull's face, but this took a LOT of trial and error to figure out which tiles made it up.

I have found a few graphics of "sprites" from this game, though they are assembled, and do not come with the locations of each of the 8x8 pieces.

Is there an easier way to determine the location of all of the sprites that make up the full character? Or is there a better way to arrange the pieces in the tile editors? Or is there some better process/tool I have not yet considered?

Any guidance or help here would be greatly appreciated.

Thanks,
JudoFlash

If you are willing to wait about a year, I am writing a tool to unscramble the tiles in Punch-Out. Why a year? I have too many other projects that I want to finish first.

Currently, all it can do is unscramble Little Mac, and a second tool to rescramble his tiles (after you edit them in a tile editor).

Another guy I know is working on a disassembly of Punch-Out, probably will take a year also.

Um, in the mean time, I came up with a cheat that prevents the opponent from hitting you. You can hit 'pause' every time the enemy's sprites change, and look at the OAM RAM copy, and write down the tiles used, find those tiles in the ROM, and use TLPs tile arranger to arrange.

Do you want me to dig up the cheat?

If you want to hide the background or the sprites, there is an option for it in FCEUX's menu:
Config > Display > Graphics: BG / OBJ

Not ideal for sprite ripping (especially if the background colour is black, and the character has black outlines), but might help a little.

Nintendulator has a video debug window that will let you look at all 64 sprite tiles and inspect their data. This could be helpful for finding the source tiles and assembling them.


You could write a really nice sprite ripping tool as an extention to FCEUX or even as a LUA script, and that could make things way easier; e.g. you could make it take a sprite snapshot each frame with all sprites currently in play, surrounded by transparency, separated by layer as best you can, etc. It's make sprite ripping exceedingly simple, but I haven't seen such a tool yet.


The mapper used for PunchOut swaps the tile sets not at a specific scanline, but when a specific sprite is hit. There can be two different tilesets in play in any given frame for both the background and foreground (so each of these layers may require inspection at 2 different scanline splits).

Maybe the best thing to do would be to find and decode the game's metasprite data, but this requires a bunch of skills for disassembly etc.

I hadn't thought about disassembling. I actually did a (bad) disassembly when I did my romhack. Maybe I'll take a look at it, see if I can spot some. Each bank seems to have specific opponent data on it, so likely they are spread throughout the entire ROM.

Also, I believe the only sprites on screen (during gameplay) are the opponent. Only BG tiles swap midscreen.

If you can find where the sprite data is located, you can hack up a rudimentary sprite viewer using FCEUX's Lua scripting; it's not exactly the same idea you explain, but I've done something like this for Tennis:



edit: of course, a BG tile viewer would need a lot more work :s

Well, another idea is if you can hack the background colour to something unused, hiding the BG layer via the menu might actually be pretty good. You can just screenshot the sprites that way.

In punch-out the background is actually the mat colour, so this is pretty good as-is with the layer toggles:


Edit: I seem to have misinterpreted OP's question; I thought you were trying to rip sprites, not modify the ROM tiles. Sorry.

I think Nintendulator's video debugger will give you the best information about where the tiles are, without digging down with a debugger and reverse engineering the metasprite data.

I checked my bad disassembly and looked at the ROM. I was able to locate some data sets for the upper half of Glass Joe, the lower half seems to go sequentially (46,47,48,49,4a,etc) and does not have a data set. But really, the sets are hard to parse and scattered throughout.

Better to go frame by frame and write down all the tile numbers. The sprite location of the RAM is $200-2ff.

The cheat to not get hit...FCEUX, Tools/Cheats...

Set RAM 76 to FF
Set RAM 77 to FF

Doesn't work well for all opponents. Some of them will loop forever if you don't punch back. Some poses only happen if you get hit.

Oh, and the first 3 sprites are tile 0 (a tiny line to the far right under the lowest rope) and tiles FD amd FE (blank, located at the top of the screen), and lots of the opponent sprites are FF (also blank). [Earlier I said the only sprites were opponent sprites, this is a correction]

Awesome. Thank you all for your detailed replies.

I had actually tweaked the display settings in FCEUX to only see the OBJ sprites, but yes, it still leaves a lot of work to be done.

I had also created a new version of the ROM where I replaced all of the graphics sprites completely, with tiles that are all individual and based on binary. However for reasons probably beyond my current level of understanding (I've never attempted a project even similar to this, and my knowledge of the NES had not gone far beyond simply playing it), it seemed the tiles I was a lot harder to simply look at these new tiles to see what was really going on behind the scenes. I could share this ROM if someone thinks it would be helpful.

I am sure I'd love to see the tool to unscramble whenever it is done, though I plan to stick with trying to solve for this in the meantime.

I'll take a look at the RAM cheat and see if that gets me any closer to a system to work through this.

Actually, a big part of my issue with my "binary" tiles is that I was trying that method BEFORE I realized you could turn off the background in FCEUX. Let me take another look and see if this is more workable now.

For a sense of what I've done, please see this screenshot (in this case, it's part of Bald Bull in the demo sequence)

Hello all,

I have continued working on this project, which is becoming a labor of love for sure. I do hope that long-term, some documentation/reference of sorts comes of this for folks who may want to edit graphics for this game in the future.

Sadly, writing a program to do any of this more efficiently is beyond my skills, but I am still enjoying the process.

As proof of concept, my goal is to first edit Bald Bull. So far, I believe I have determined 98% of the tiles used for each one of his animation frames. I say 98% as a few frames seem to use some tricks that make deciphering the tiles more difficult (moreso than just mirroring or offsetting - I believe in some cases they are offset and overlapping so I simply cannot read the hex labels I put on my customer ROM).

Anyhow, I've tried researching this online, but I seem to be bumping against a fairly common problem, and that is one of palettes.

More specifically, I have created some new graphics that I am trying to import into either tlp (probably my first choice) or YY-CHR. Note that I will use whatever tool I need to. The issue I have is, even though I have ensured that my files are only 4 colors (the exact ones of the game), when I import them, the colors seem to completely change. This is true even if I set the palette in the tool to match the graphics, or vice versa.

Presently I am using GIMP for my graphics editing, and have been saving as 4-color indexed BMP's. Again, I can adapt as needed, though I'd prefer not to purchase any software if I can help it.

So, other than overall advice on process (which I will gladly take), my question is this - does TLP try to dither to the colors its palette is set to (if so, it is not doing so properly), or does it simply read the index and simply say the "first" color of the BMP is color 1, the second is color 2, etc. if so, I will see if I can figure out how to simply reassign the palette and rebuild my graphics - but this hasn't been intuitive enough for me to try yet.

Any guidance would be awesome. Thanks!

This is a common problem.

The method you described...



Is the correct method, but I've heard lots of complaints that -- both YY-CHR and TLP -- screw this up, often.

I prefer YY-CHR, because it at least has a color replacement tool, to fix the failed indexing. Just select the tiles you want to fix, click on the tool (it looks like 3 squares and an arrow to 3 other squares). Also, you can cut and paste from GIMP to YY-CHR.

Thanks so much for the quick reply.

One thing I failed to mention - the reason I was leaning toward TLP over YY-CHR is that when I import into YY-CHR, the graphic itself seems to be scrambled. Almost like I am importing in the wrong format - the best way I can describe it is that it ends up with a lot of vertical lines.

I imported a larget image to illustrate, though the results are the same. Please see the screenshot here:

You don't happen to have python installed on your computer, do you? I think tepples wrote a python script for converting a picture to nes format

Right? Or a tool or something?

I do not. When you say convert to the NES format, do you mean a bmp that is compatible, or a more native format like CHR or something.

As I think of it, I suppose I could first import all of the tiles into TLP, then use the palette swapping features in yy-chr to adjust them afterwards. This would still be somewhat of a pain as I would need to be careful, since I don't plan to change every single tile in the set.

He made both...

In this link (240p)...
viewtopic.php?p=161288#p161288

is a python script called pilbmp2nes.py which converts a bmp file to nes chr file

and on his website...

http://www.pineight.com/pc/#ted

appears to be a command line tool called bmp2tiles which seems to do the same thing without python.

correct me if I'm wrong, tepples.





When you view an NES game or CHR file in YY-CHR / TLP, that is what I mean by 'NES format'. I don't want to get into the boring technical details, but it's a series of bitplanes that the NES PPU can index to a 4 color palette to generate an image.

It has been a while since I have touched this project, but have been thinking of picking it up again.

dougeff: I don't suppose you have done any development on the sprite scrambler/unscrambler, have you?

I got busy working on other things. Don't know if I'll ever get back to that.

Understandable, but figured it was worth asking. Thanks!