I'm making a graphic mod to Hogan's Alley using Tile Layer Pro, but whenever I save the new rom file, the zapper function no longer works on the emulators I'm using and renders the game unplayable. The original works fine using the mouse as the zapper. Is there a way to fix this? I want to be able to play the game on an emulator as well as port it to a cart to play on an NES. I attached the rom file in question if anyone wants to give it a look. Thanks!
The Zapper can see only light and dark. Different emulators have different behavior for what they consider "light" or "dark". If a "light" area isn't light enough, the emulator will report a miss to the game.
Maybe the emulators are choosing whether to enable the zapper by hashing the ROM and comparing against a database of known zapper games? If that's the case there's not much you can do besides looking for the option to turn the zapper on manually.
I don't understand why when I make a small change to the rom, the emulators suddenly don't recognize the zapper function. They work perfectly fine before. What changes when I save the file in Tile Layer Pro? I just want to know how to mod a zapper game so it's playable on an emulator.
Many emulators use a
hash function to identify ROM images of individual commercial games so that the emulator can plug in reasonable settings without the user having to go to the trouble of setting up the emulator himself. When you make even the smallest change, the hash function produces a different value. For a user using only well-known commercial games, this provides the best user experience at the cost of a poor user experience when using ROM hacks or original homebrew games. Some emulator developers consider this an acceptable tradeoff.
It might be easier for you to understand if I provide a worked example. Applying the CRC32 hash function to the PRG ROM of
Hogan's Alley produces the value $8963AE6E, and applying it to the CHR ROM produces $5DF42FC4. The database shipped with an emulator may have an entry to the effect "When the PRG ROM is 128 Kbit with CRC32 $8963AE6E, and the CHR ROM is 64 Kbit with CRC32 $5DF42FC4, emulate a Zapper plugged into port 2." When you edit the tiles, the CRC32 value changes to something other than $5DF42FC4, causing this rule not to trigger.
You might have to manually enable the Zapper in your emulator. The process for doing this will vary from one emulator to the next. Have your users read the manual of the emulator that they use.
Have you tried your modified game on an NES with a Zapper and a CRT SDTV?
Wow, thank you! Evidently changing the emulator input for port 2 to zappers worked. I just tried using port 1 to no avail. My next step is putting the game onto a cart and actually using it with a zapper and CRT SDTV, but I wanted to make sure it would work before I put money into getting the cartridge made.
You could try buying an EverDrive N8 or a PowerPak. These are adapters to let you use digital camera memory (SD or CompactFlash) in an NES. You load the game onto the memory card using your PC, stick it in the adapter, and put the adapter in your NES.
I've encountered this problem many times now. It makes things really difficult for ROM-hackers or homebrewers. This checksum stuff is bad behaviour if you ask me (as discussed in other threads).
In the long term, perhaps a better way to say "enable Zapper only for this homebrew game" might be
zzo38's metadata proposal, which specifies recommended controllers for a game among other things. But even that might fail for things like a multicart.
Does iNES 2 have a field for suggested controllers?
No. Every bit in NES 2.0 relates to something soldered onto the game's printed circuit board. It doesn't specify what plugs into the Control Deck, which is where zzo38's proposal comes into play.
Compeltely pointless, except for searching for games. I mean, my game uses 2 controllers. And you'll still have to have the menu in the game to pick them, and should have the menu. It should not be picked up the images for what controller to use, completely worthless to do from a usability standpoint, it only adds crap, it doesn't simplify emulation development, only makes it worse.
Clearly, the emulator authors using a CRC solution thought it improves usability to automatically select the appropriate controllers to use instead of having their users manually configure them upon switching games.
I'd tend to agree. Instead of 1000 users being confused about why Duck Hunt doesn't work, you have 2 users confused why some Duck Hunt romhack doesn't work.
A suggested peripheral setup in the header would alleviate the issue entirely. The other great thing about emulators is that they have options. If you want your emulator to allow someone to play the Duck Hunt ROM with two controllers instead, it can ignore the suggestion, or allow it to be overridden.
Having more information in the header doesn't simplify emulator development if you don't want to use it, sure, but in the same situation it doesn't complicate it either (just another byte to ignore). That's not the goal, though, the goal is to simplify the user's experience. The number of users is orders of magnitude larger than the number of people developing the emulator. (Also, if the emulator developer was frustrated enough by the problem to put in a CRC based solution, clearly this will simplify it for them.)
The point is NOT emualtor usability, but the ability to represent the cartridge type, and what hardware the CART contains, in a file. I'd rather have a CRC program than header addition, because it's pretty wasteful for the header to contain that garbage. I mean, aren't there more than 16 additional controllers? I'd bet. And that makes it basically 2 bytes, prefered and extra, unless you only go with one controller. Or have the 1 byte represent every combination ever used. But no matter what, having it in the header is a shitty idea.
Which is why zzo38 suggested to put controller configuration (and other metadata about the game) in a separate file.
3gengames wrote:
The point is NOT emualtor usability, but the ability to represent the cartridge type, and what hardware the CART contains, in a file. I'd rather have a CRC program than header addition, because it's pretty wasteful for the header to contain that garbage. I mean, aren't there more than 16 additional controllers? I'd bet. And that makes it basically 2 bytes, prefered and extra, unless you only go with one controller. Or have the 1 byte represent every combination ever used. But no matter what, having it in the header is a shitty idea.
So, your worst case is 2 bytes? The current spec actually has 2 bytes of padding in the header, by the way... do you think 2 bytes of zero information is also wasteful? Having separate files wastes far more than 2 bytes just for the file record.
1 byte is probably sufficient, though. I think there are far, far less than 256 useful controller setups. The wiki lists about 20 potential input devices, and most of them are really only used in one configuration; we don't need every permutation, just the ones that were used by games. If some new homebrew wants to use a novel configuration, it can be allocated a new index just like mappers are.
I don't understand your objection to having this information included in the NES file. So what if it's not part of the cartridge? The NES zapper is a part of the game Duck Hunt just as much as the cartridge is. It's not playable without it. The famicom keyboard came in the package with Family Basic. The SNES mouse came packaged with Mario Paint. They're not the slightest bit inessential to emulating these games properly.
How would you handle games that can use more than one type of controller? SMB/DH needs a controller in port 2 for Luigi in SMB1 but a Zapper in port 2 for Duck Hunt. SMB/DH/WCTM needs even more setups. The first Action 53 multicart can use controller, controller+Zapper, Zapper+Zapper, controller+mouse, or (I think) mouse+mouse. Would an entry in a controller registry be needed for each combination?
Well, I look at it similarly to how I would treat a PAL/NTSC flag. This flag tells you what configuration the cartridge is intended to be plugged into. It's a default setup, not necessarily a list of all things it could use. Unless overridden by the user, an .NES flagged as PAL should start up in PAL emulation mode. If the ROM supports both, the user will need to select the non-default option manually. (Would 3gengames suggest doing PAL detection by CRC too? It's certainly not part of the cartridge.)
For all three cases you mentioned, the standard 2 controller setup (most likely identified by the number 0 in this scheme) is a perfectly appropriate default. If desired, one of the setup entries could be "multi", which defaults to 2 controllers but is letting you know that this game has multiple peripheral configurations.
A "multi" option most likely doesn't make it easier or harder for an emulator user, but it might help organize your ROMs with automated tools (e.g. display all zapper games).
Back to the PAL flags, it looks like the current spec has: 0 NTSC, 1 PAL, 2 both but default NTSC, 3 both but default PAL. I think the lack of Dendy is a glaring omission, but ignoring that for the moment, this does cover all the non-Dendy use cases. NSF has the same two-bit field, more or less, and it led me to give the user 6 options in NSFPlay: 0 use default, 1 prefer NTSC for dual, 2 prefer PAL for dual, 3 force NTSC, 4 force PAL, 5 force Dendy.
For peripheral setup, I don't think a bitfield would work very well. There'd be too many bits (at least 32?), and the number of useful combinations is very sparse (~30?). NSF made expansions a bitfield, and the homebrew music crowd made a horrendous and/or wonderful mess out of it-- this bitfield was probably a mistake (but a fun one). I think an indexed registry like we have with mappers would work well. Something like:
0 - 2 controllers (generic, neither microphone or controller 2 start is essential)
1 - multi (2 controllers default)
2 - zapper in 2
3 - 2 controllers NES (start on controller 2 is essential)
4 - 2 controllers Famicom (microphone is essential)
5 - track and field pad
6 - family basic keyboard
7 - R.O.B. gyromite mode
8 - R.O.B. stack up mode
9 - power glove
10 - family basic keyboard
11 - miracle piano
etc... (a lot of these will be one-offs)
Unlike mappers, it's also very optional. The user should normally be able to override the suggested setup, and a minimalist emulator author could ignore it entirely.
Even though it's not technically a part of the cartridge, if you ever used the CIC chip, or used any cart to PC hardware, you would need to know the clock, so it makes sense a PAL/NTSC flag is in the header, as the hardware is dependent on that. But also, you forgot the vaus+normal controller set up, my game can use all 4 combinations, and if I decide to add my mini game, my game will support 6 input configurations.