ROMHacking Thread
Posted: Tue Sep 29, 2020 1:54 am
NES Romhacking
Tools used:
Photoshop (or other art program, such as Aesprite, Tiled, Clip Studio Paint)
YY-CHR (graphics replacement), Tile Layer Pro is also a possibility
Mesen (NES emulator, HDPacks, Nametable dumping, sprite/layout/graphics viewing, etc)
FCEUX (NES emulator, hex editor for real-time reprogramming with text table support)
Shiru's NES Screen Tool (Background/sprite graphics layout design) or NEXXT by Frankengraphics
NAW (NES Assets Workshop) MarioNesRocks
Hex editor (any will do)
Notepad
Oriton table creator (text table creation)
Lunar IPS (create/run IPS patches, used to distribute ROMhacks as "changed bytes only" for copyright reasons)
CADEditor for NES level editing
i-CHR
NintendulatorNRS (for running VT03 and games with unusual Mappers)
VirtuaNES and NESTopia (for Family Basic compatibility, with STTONES)
ZSNES (Super NES Save States for color palettes)
Romhacking.net (website)
--------------------------------
The graphics (CHR) bank in an NES game is a 128x128 image that looks like this:
Every square there is a new 8x8 sprite.
Here's one of the sprite sheets from Karate Kid, followed by a background graphics sheet at bottom, which includes the title screen and the cheering crowd.
https://imgur.com/a/5DHirs6
I pulled this using the Mesen emulator to look at the CHR banks in the PPU Viewer, modifying palettes to make it more visible.
Here are alternate graphics from the existing RomHack Cobra Kai, and tweaked versions by Silent_J.
https://i.ibb.co/vmBJHkR/Cobra-Kai-Karate-Kid-NES.png
To make different graphics work in the actual game, you'd need to go through these 8x8 pixel tiles in Photoshop (maybe using the checkerboard image I posted as an overlay at low opacity), and compare them to a sprite sheet of the characters, and a modified version of that same artwork (which would be on another matching layer).
For my Monster Party hack, I put together matching sprite sheets from the normal game and from a redesign. I then went through block by block, looked for each sprite block, found it, and pasted the modified sprite over it as a replacement layer.
This replaced art can then run in Mesen as an HDpack and can be pasted into the actual ROM using YY-CHR or a similar program.
To alter text in a game, I use the FCEUX emulator and open up the hex editor. I probably need to create a lookup table, or LUT. For Monster Party I used Oriton Table Creator. I looked at where the text font is stored in the CHR graphics, and noted the number of each sprite (using the PPU/CHR viewer in Mesen or FCEUX). So I create a lookup table which translates each letter in the font to the location of that letter in the graphics.
The number of tiles you use for your title screen should match those used for the original, since it will have to fit in the same space in the CHR bank. You may also have to duplicate the layout of the original, as its blank tiles may have to stay blank. Shiru's Screen Tool may come in handy, as may I-CHR.
https://shiru.untergrund.net/software.shtml
____________
Notes on current hack progress:
When copy/pasting new graphics into YY-CHR, the colors will always be assigned wrong, but since it's a four-color system this only takes seconds to fix.
At this point, a lot of the graphics tiles have been replaced (using YY-CHR), and often they're not in the same place as the originals because we're planning to do a something a little different with the characters. The wrong tiles are displayed, in the wrong colors. This has to be corrected by looking at the hexadecimal code in FCEUX using the code/data logger. The code is just a bunch of numbers, which mean something different in different contexts, but I should be able to find where these specific tiles are and change the numbers.
Tiles are all 8x8. Sprite tiles can choose from 1 of 4 four-color palettes. Background tiles can be recolored in 16x16 blocks made up of four tiles.
_____________
So looking in CadEditor gives a good example of how most NES games handle level layouts.
[Image]
Sometimes, especially on a title screen, you would define everything on a tile by tile basis, probably also using control codes to jump around the screen and save code space. You would then have an attribute table, setting colors in 2x2 blocks.
But in this case, and on the title screen and shop and ending, we're dealing with 2x2 blocks throughout.
From the selection of graphics tiles at right, we've defined a number of 2x2 blocks of tiles, with one of four color palettes selected, and probably collision detection set as well.
The entire level layout is then done from those sets of 2x2 blocks rather than on a 1x1 tile basis.
(Note that background color can be changed on a 2x2 block basis while sprite color can be changed on every single tile. A tile is 8x8, a block is 16x16.)
Without CadEditor I was editing four separate tables for each screen. The graphics bank, the block definitions, the block palettes and types, and the level layout.
I would do this from trying to find numbers in the hex code which seemed to match what I'm trying to do. It's not visual but I can refresh the ROM to see if I'm right.
A set of graphics tiles on the NES is four colors (and can use four palettes for background and four for sprites). Each tile is numbered from 00 to FF, as seen below.
[Image]
That's 128x128 pixels, made up of 8x8 tiles. That's smaller than the NES's resolution of 256x240, so get ready to be clever and reuse tiles.
Related: Did you know the clouds in Super Mario Bros are also the bushes?
Since every tile is numbered, it is usually possible to find in the hex code where the tiles are being defined and used, and type in a different number for that in order to use different tiles and change appearance.
There may be two different tables for sprites -- such as a table which defines which tiles are used and their palette number, and whether they're being flipped or not -- and then a table for their position onscreen.
You can only display a limited number of sprites on a single line. The sprites will start to become invisible when too many enemies are onscreen, for example. (Modern emulators can turn this on and off but lots of onscreen sprites also slows down the game.)
Backgrounds have no such restrictions.
Generally the player character and any enemies would be sprites.
Emulators also have a debugger which attempts to reconstruct the original assembly code instructions based on what numbers appear in the hex code.
I don't usually use these, and they're not entirely accurate, but better hackers are using these all the time. You might attempt to disassemble the code in a similar fashion. Some of the more popular games have gotten disassemblies which attempt to make the code much more understandable. I used this on my Super Mario Bros 2 hack. This isn't usually available with the games I'm hacking and the SMB2 hack was still difficult, as the disassembly didn't quite explain everything. It explained most things though.
In order to help you find what parts of the hex code are being used at any time, FCEUX (emulator) has a Code/Data logger. A code disassembler will also require this. You can run it for short periods of time while playing the game, and the code that's being used will light up (or can be saved to file on its own). This is usually enough to help you find the code you need to change.
Generally, two CHR graphics banks are used at any one time - one for backgrounds and one for sprites. Early NES games only used two graphics banks period (known as Mapper Zero games). Later games used more advanced Mapper chips to switch between different graphics banks, sometimes in the middle of gameplay, and sometimes combining pieces of several different CHR graphics banks into one inside the NES's graphics PPU.
Donald Land is a very normal NES game for this period. It uses one background sheet and one sprite sheet at a time, and switches them between levels, or when loading a different set of enemies.
We can view and change these graphics sheets in YY-CHR or similar programs.
Tools used:
Photoshop (or other art program, such as Aesprite, Tiled, Clip Studio Paint)
YY-CHR (graphics replacement), Tile Layer Pro is also a possibility
Mesen (NES emulator, HDPacks, Nametable dumping, sprite/layout/graphics viewing, etc)
FCEUX (NES emulator, hex editor for real-time reprogramming with text table support)
Shiru's NES Screen Tool (Background/sprite graphics layout design) or NEXXT by Frankengraphics
NAW (NES Assets Workshop) MarioNesRocks
Hex editor (any will do)
Notepad
Oriton table creator (text table creation)
Lunar IPS (create/run IPS patches, used to distribute ROMhacks as "changed bytes only" for copyright reasons)
CADEditor for NES level editing
i-CHR
NintendulatorNRS (for running VT03 and games with unusual Mappers)
VirtuaNES and NESTopia (for Family Basic compatibility, with STTONES)
ZSNES (Super NES Save States for color palettes)
Romhacking.net (website)
--------------------------------
The graphics (CHR) bank in an NES game is a 128x128 image that looks like this:
Every square there is a new 8x8 sprite.
Here's one of the sprite sheets from Karate Kid, followed by a background graphics sheet at bottom, which includes the title screen and the cheering crowd.
https://imgur.com/a/5DHirs6
I pulled this using the Mesen emulator to look at the CHR banks in the PPU Viewer, modifying palettes to make it more visible.
Here are alternate graphics from the existing RomHack Cobra Kai, and tweaked versions by Silent_J.
https://i.ibb.co/vmBJHkR/Cobra-Kai-Karate-Kid-NES.png
To make different graphics work in the actual game, you'd need to go through these 8x8 pixel tiles in Photoshop (maybe using the checkerboard image I posted as an overlay at low opacity), and compare them to a sprite sheet of the characters, and a modified version of that same artwork (which would be on another matching layer).
For my Monster Party hack, I put together matching sprite sheets from the normal game and from a redesign. I then went through block by block, looked for each sprite block, found it, and pasted the modified sprite over it as a replacement layer.
This replaced art can then run in Mesen as an HDpack and can be pasted into the actual ROM using YY-CHR or a similar program.
To alter text in a game, I use the FCEUX emulator and open up the hex editor. I probably need to create a lookup table, or LUT. For Monster Party I used Oriton Table Creator. I looked at where the text font is stored in the CHR graphics, and noted the number of each sprite (using the PPU/CHR viewer in Mesen or FCEUX). So I create a lookup table which translates each letter in the font to the location of that letter in the graphics.
The number of tiles you use for your title screen should match those used for the original, since it will have to fit in the same space in the CHR bank. You may also have to duplicate the layout of the original, as its blank tiles may have to stay blank. Shiru's Screen Tool may come in handy, as may I-CHR.
https://shiru.untergrund.net/software.shtml
____________
Notes on current hack progress:
When copy/pasting new graphics into YY-CHR, the colors will always be assigned wrong, but since it's a four-color system this only takes seconds to fix.
At this point, a lot of the graphics tiles have been replaced (using YY-CHR), and often they're not in the same place as the originals because we're planning to do a something a little different with the characters. The wrong tiles are displayed, in the wrong colors. This has to be corrected by looking at the hexadecimal code in FCEUX using the code/data logger. The code is just a bunch of numbers, which mean something different in different contexts, but I should be able to find where these specific tiles are and change the numbers.
Tiles are all 8x8. Sprite tiles can choose from 1 of 4 four-color palettes. Background tiles can be recolored in 16x16 blocks made up of four tiles.
_____________
So looking in CadEditor gives a good example of how most NES games handle level layouts.
[Image]
Sometimes, especially on a title screen, you would define everything on a tile by tile basis, probably also using control codes to jump around the screen and save code space. You would then have an attribute table, setting colors in 2x2 blocks.
But in this case, and on the title screen and shop and ending, we're dealing with 2x2 blocks throughout.
From the selection of graphics tiles at right, we've defined a number of 2x2 blocks of tiles, with one of four color palettes selected, and probably collision detection set as well.
The entire level layout is then done from those sets of 2x2 blocks rather than on a 1x1 tile basis.
(Note that background color can be changed on a 2x2 block basis while sprite color can be changed on every single tile. A tile is 8x8, a block is 16x16.)
Without CadEditor I was editing four separate tables for each screen. The graphics bank, the block definitions, the block palettes and types, and the level layout.
I would do this from trying to find numbers in the hex code which seemed to match what I'm trying to do. It's not visual but I can refresh the ROM to see if I'm right.
A set of graphics tiles on the NES is four colors (and can use four palettes for background and four for sprites). Each tile is numbered from 00 to FF, as seen below.
[Image]
That's 128x128 pixels, made up of 8x8 tiles. That's smaller than the NES's resolution of 256x240, so get ready to be clever and reuse tiles.
Related: Did you know the clouds in Super Mario Bros are also the bushes?
Since every tile is numbered, it is usually possible to find in the hex code where the tiles are being defined and used, and type in a different number for that in order to use different tiles and change appearance.
There may be two different tables for sprites -- such as a table which defines which tiles are used and their palette number, and whether they're being flipped or not -- and then a table for their position onscreen.
You can only display a limited number of sprites on a single line. The sprites will start to become invisible when too many enemies are onscreen, for example. (Modern emulators can turn this on and off but lots of onscreen sprites also slows down the game.)
Backgrounds have no such restrictions.
Generally the player character and any enemies would be sprites.
Emulators also have a debugger which attempts to reconstruct the original assembly code instructions based on what numbers appear in the hex code.
I don't usually use these, and they're not entirely accurate, but better hackers are using these all the time. You might attempt to disassemble the code in a similar fashion. Some of the more popular games have gotten disassemblies which attempt to make the code much more understandable. I used this on my Super Mario Bros 2 hack. This isn't usually available with the games I'm hacking and the SMB2 hack was still difficult, as the disassembly didn't quite explain everything. It explained most things though.
In order to help you find what parts of the hex code are being used at any time, FCEUX (emulator) has a Code/Data logger. A code disassembler will also require this. You can run it for short periods of time while playing the game, and the code that's being used will light up (or can be saved to file on its own). This is usually enough to help you find the code you need to change.
Generally, two CHR graphics banks are used at any one time - one for backgrounds and one for sprites. Early NES games only used two graphics banks period (known as Mapper Zero games). Later games used more advanced Mapper chips to switch between different graphics banks, sometimes in the middle of gameplay, and sometimes combining pieces of several different CHR graphics banks into one inside the NES's graphics PPU.
Donald Land is a very normal NES game for this period. It uses one background sheet and one sprite sheet at a time, and switches them between levels, or when loading a different set of enemies.
We can view and change these graphics sheets in YY-CHR or similar programs.
