as refresh_rate usually refers to a number of frames/fields per second.
This also avoid the confusion with the newly introduced
vi.expected_refresh_rate field.
The controller problem seems to be related to the graphics plugin. A quote from
darkmaster14
"I believe the Pokemon Snap input issue is closely related to the missing red
dot issue. If you recall, in the original hardware, when you first arrive on
the beach, there's a small tutorial where you can't move the cursor until you
take a picture of the first few Pokemon that show up. Once you finish the mini
tutorial, you can move the cursor around as you please. Well, the red dot
doesn't work on most plugins, so the game doesn't detect the cursor locking
onto the first few Pokemon, so the tutorial doesn't work, and thus the input
never gets unlocked.
Well, I got a hold of a very buggy port of FatCat's software renderer plugin
for Mupen64Plus, and the red dot works on that, which lets you do the tutorial,
and thus the cursor movement is unlocked and you can play the game as normal.
So really, the problem most likely lies in the video plugins rather than the
emulation core. I'm guessing on Project64, however, they added a hack to force
the cursor to move around despite the red dot not working, which is why it
works on that emulator."
This fix is used in PJ64 to avoid the big landing shadow block. But it can
cause hangs when the user presses Quit (can be reproduced in PJ64+m64p when
using the rocket in 3FCD4969F9A080BD2BCB913EC5D7A3BD).
It is a lot easier to add the workaround cheats to the mupen64plus.ini instead
of having them hardcoded in the cheat engine. The data is currently not used
because it still has to be parsed by the romdatabase before these general
workaround cheats are supported.
The cheat code consists of three pairs of precondition and actual write. The
original code used two different preconditions (one for the first write and two
for the second/third write). This caused problems like the inability to finish
a level. Using the same precondition everywhere seems to fix this problem.
The CountPerOp settings has to be adjusted for each ROM. It is easier for the
enduser when the default value is not hardcoded in mupen64plus and instead
this dynamic information is retreived from the mupen64plus.ini.
