Zapper games rom mod not working

[quietquiet]

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!

[tepples]

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.

[tokumaru]

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.

[quietquiet]

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.

[tepples]

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?

[quietquiet]

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.

[tepples]

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.

[oRBIT2002]

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).

[tepples]

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.

[rainwarrior]

Does iNES 2 have a field for suggested controllers?

[tepples]

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.

[3gengames]

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.

[rainwarrior]

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.)

[3gengames]

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.

[tepples]

Which is why zzo38 suggested to put controller configuration (and other metadata about the game) in a separate file.