In the meanwhile, a much simpler fix is to set Settings.Appl圜heats to TRUE in the GTK front by default, since it was apparently designed this way. Apparently its UI was designed with the idea that cheats would be enabled or disabled on an individual basis, not globally.Ī proper fix would thus to let add the possibility to enable/disable Settings.Appl圜heats from the GTK UI. 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.Appl圜heats. So Snes9x falls back to the default value, FALSE.
And Settings.Appl圜heats is conspicuously missing form there. Not all the possible Snes9x settings are covered in that format the GTK front populates those with its own defaults. By default, Settings.Appl圜heats is FALSE, though, and is only set to TRUE if the configuration file loaded through the mechanism described above contains a section with the line 'Cheat=true'.Īnd 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. 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.Appl圜heats is TRUE.
Snes cheat codes for zsbes code#
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.Appl圜heats, which is the relevant setting here.
It looks like Snes9x provides hooks for ports to implement configuration loading in conffile.h. The issue is specific to the GTK version and has to do with the configuration subsystem.
0 kommentar(er)
