Snes9x.com

Hi,

I hope this is the correct place to report bugs.

VERSION: snes9x-gtk 1.52
ARCH: Linux amd64

ISSUE DESCRIPTION:
When using a known good Action Replay code (specifically: 7e9a1b64, which pins Ness's PP to 100 in Earthbound), Snes9x seems to apply the value once, but it doesn't 'stick', i.e. regular game events decrease this value as if the cheat was disabled.

Toggling the AR code off then on again resets Ness's PP to 100, but again, the value doesn't stick through usual game events (i.e. casting PSI spells).

I tested the same AR code in ZSNES; it works as expected there.

It looks like the algorithm that 'pins' the AR-specified byte in the emulated memory isn't called when an emulated CPU opcode attempts to modify that byte. Weird.

I hope this helps.

Ok, that was not too bad.

The issue is specific to the GTK version and has to do with the configuration subsystem.

It looks like Snes9x provides hooks for ports to implement configuration loading in conffile.h. The code in snes9x.cpp:S9xLoadConfigFiles() expects the configuration to be loaded through that hook and uses the result thereof to populate the Settings struct, and in particular, Settings.ApplyCheats, which is the relevant setting here.

The cheats are not 'pinned' when the relevant memory section is written to like I thought (goes to show what I know), but every frame, if and only if Settings.ApplyCheats is TRUE. By default, Settings.ApplyCheats is FALSE, though, and is only set to TRUE if the configuration file loaded through the mechanism described above contains a [ROM] section with the line 'Cheat=true'.

And that would be the source of the problem: the GTK front bypasses the regular configuration file loading, and implements its own, in a completely different format. Not all the possible Snes9x settings are covered in that format; the GTK front populates those with its own defaults. And Settings.ApplyCheats is conspicuously missing form there.

So Snes9x falls back to the default value, FALSE. But the GTK fronts behaves for all intents and purposes like cheats are on by default! The UI for cheats remains enabled regardless of Settings.ApplyCheats. Apparently its UI was designed with the idea that cheats would be enabled or disabled on an individual basis, not globally.

A proper fix would thus to let add the possibility to enable/disable Settings.ApplyCheats from the GTK UI. In the meanwhile, a much simpler fix is to set Settings.ApplyCheats to TRUE in the GTK front by default, since it was apparently designed this way.

There's a second underlying issue, where cheats were applied once when toggled in the GTK UI even with Settings.ApplyCheats being FALSE, causing more confusion still. This is because the GTK UI calls cheats2.cpp:S9xEnableCheat(), which itself unconditionally calls S9xApplyCheat(). This too is easily fixed.

Hence the proposed patch. This patch was generated against the 1.52 source code as made available in Ubuntu.

IIRC this has already been fixed in the current git revision, but thanks anyway.

OV2 wrote:IIRC this has already been fixed in the current git revision, but thanks anyway.

Darn! I didn't know there was a git repo. It's not linked from the Snes9X Web site, is it? (I thought I'd checked...)

But anyway, good that the issue is already corrected, then. :)

We still don't have access to the frontpage, so no, it's not linked.

You can find it here: https://github.com/snes9xgit/snes9x