Punch-out graphics hacking help
Moderator: Moderators
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
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
Re: Punch-out graphics hacking help
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?
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?
nesdoug.com -- blog/tutorial on programming for the NES
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Punch-out graphics hacking help
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.
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.
Re: Punch-out graphics hacking help
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.
Also, I believe the only sprites on screen (during gameplay) are the opponent. Only BG tiles swap midscreen.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Punch-out graphics hacking help
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:rainwarrior wrote: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.
edit: of course, a BG tile viewer would need a lot more work :s
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Punch-out graphics hacking help
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.
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.
Re: Punch-out graphics hacking help
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]
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]
nesdoug.com -- blog/tutorial on programming for the NES
Re: Punch-out graphics hacking help
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.
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.
Last edited by JudoFlash on Sun May 29, 2016 8:49 am, edited 1 time in total.
Re: Punch-out graphics hacking help
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)
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)
Re: Punch-out graphics hacking help
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!
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!
Re: Punch-out graphics hacking help
This is a common problem.
The method you described...
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.
The method you described...
saving as 4-color indexed BMP
Is the correct method, but I've heard lots of complaints that -- both YY-CHR and TLP -- screw this up, often.even if I set the palette in the tool to match the graphics
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.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Punch-out graphics hacking help
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:
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:
Re: Punch-out graphics hacking help
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?
Right? Or a tool or something?
nesdoug.com -- blog/tutorial on programming for the NES
Re: Punch-out graphics hacking help
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.
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.
Re: Punch-out graphics hacking help
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.
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.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.
nesdoug.com -- blog/tutorial on programming for the NES