I'm well aware cheat support in Bizhawk is shoddy at best, but I recently came across an oddness in the implementation that seemed like it was introducing overhead which I couldn't quite see a reason for. Within the main emulation step loop, Global.CheatList.Pulse() is called twice.
Before the frame advance
and
After the frame advance
This seems to me like it's introducing unnecessary overhead, but I may be missing the reasoning for it being called twice under all circumstances.
Obviously, it needs to apply before frame 0. That means you need to set the value before the first frame advance. You then need to constantly set the value before the next frame advance as well.
Applying twice solves this problem. You set the value before the first frame advance, step, then write the value back. Anything that needs to check the value after the step still gets the correct value as it was written back.
At that point though, applying pre-step seems pointless outside of the very first step.
I personally can't come up with any cases where the value would have changed between frame end and the start of the next frame (outside of a lua script overwriting the value in either the frameend or the next framestart event). Framestart is currently called after the initial cheat pulse anyways so that can already overwrite the value.
I get the reasoning for having the tools update before and after every step, but why pulse cheats twice (outside of the first step)? Am I missing something, is it done that way for consistency sake (since everything else is called before and after a step), or is it just an issue in the implementation?
