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.
Instead of hardcoding special commands in cheat_apply_cheats, it is easier to
just use add the codes to the active cheats list when the the rom is started.
This avoids having more string compares and similar things in this regularly
called routine when more workaround cheats are added.
This is especially helpful against the slowdowns in the Zelda debug roms caused
by the "Warning: Ocarina of Time version could not be determined. No fixes
applied." spam on the console.
The behavior of the romdatabase_resolve was to overwrite any setting when the
referenced rom had non-default settings. This made it impossible to use
references when the referenced rom has different settings than the rom who
references it.
The old rom database algorithm tried to resolve (refMD5) entries immediately in
romdatabase_open without checking the referenced entry. This algorithm caused
entries to be used when they are still have uninitialized fields because the
referenced entry still has some other entries which it referenced.
Using only complete (resolved) entries also allows to detect loops
(unresolvable references) as seen before
304bf8c4de ("Fix self-references in
mupen64plus.ini")
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.
Each cheat code can have multiple preconditions which all have to be fulfilled
before it can be executed. The default implementation in mupen64plus could not
handle these extra test codes because a failed test only caused a jump over the
next cheatcode (ignoring whether is also a test or a non-test cheatcode).
Therefore, all (negative) results before a non-test cheat code have to be
aggregated. The first non-test cheatcode evaluates the result of the
preconditions and only executes the non-test cheatcode when no precondition
test failed. The earlier results are always dropped after a non-test cheatcode
to allow a fresh start.
All "Jump and link" and "Branch and link" like instructions save the PC in the
target register unconditionally and not only when the branch/jump is taken.
The specification is not clear whether the store is actually made before or
after the delay slot and therefore the behavior of the dynarecs ("link" before
delay slot) is used.
Reported-by: Nebuleon <nebuleon.fumika@gmail.com>
Instead of trying to access the wayland window through SDL_GetWindowSurface,
it seems to be easier to just use a pseudo surface which is not really used by
anyone (except the size information).
SDL2 doesn't close windows anymore when the video subsystem is closed.
Therefore, the window created by the SDL2 compat layer has to be closed
manually to avoid orphan windows in frontends like m64py in non-VidExt mode.
mupen64plus doesn't support 2D video output because it forces OPENGL mode.
Unfortunately, the rest of the compat code still assumes that surfaces for 2D
data are used and overwrites the data when the window is changed.
The surface code can be removed to avoid these problems.
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.
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.
The rounding mode is completely unneeded when converting from W (32-bit integer) or S (32-bit floating-point) to D (64-bit floating-point), and is actually unused on MIPS processors.
Quoting from the MIPS Programmer's Manual, volume 2, for CVT.D.fmt:
The value in FPR fs, in format fmt, is converted to a value in double floating point format and rounded according to the current rounding mode in FCSR. The result is placed in FPR fd. If fmt is S or W, then the operation is always exact.
Setting the rounding mode on some host architectures (including x86, according to <http://www.mega-nerd.com/FPcast/>) empties the floating-point unit's pipeline, resulting in poorer performance. Omitting the rounding mode before exact operations restores some performance.
Affected opcodes are CVT.W.S, CVT.W.D, CVT.L.S, CVT.L.D, ABS.S, MOV.S, NEG.S, ABS.D, MOV.D and NEG.D.
The JR_IDLE and JALR_IDLE functions are unused in the pure interpreter and
cached interpreter. Thus these functions are marked with the attribute
"unused". Unfortunatelly, the declaration did not precede the definition. Also
the definition conflicted with the declaration.
The second part of the credit cheat were executed independenly of the first
part. This was caused but the wrong syntax used for the if statement in commit
8e14cc9ba5 ("Add Missing Subscreen Delay Fix for
Ocarina of Time")
GCC cannot identify the rdramb pointer as const and therefore not remove any
indirection when using it without link-time optimization. The missing const
reduces the performance slightly in (read|write)_rdram[bhd]? because extra
instructions have to be generated to get the value of rdramb from memory.
Reported-by: Nebuleon Fumika
