In the RSP, MFC0, MFC2, and CFC2 were all susceptible to overwriting $zero. Some of us have tried waiting for some games to use handcoded assembly in an attempt to purposely overwrite $zero in their microcode (to throw off emulators), but so far what few occurrences there have been of this have not included using those 3 opcodes. Since it was decided to centralize the security of register $zero in the main R4300 CPU, it was decided to do so in the RSP as well.
In both the 32- and the 64-bit interpreters, ADDI, LUI, LB, LW, LWU, LL, SLLV all check if the destination register specifier is 0, when none of the other interpreter ops do. Actually, none of these 7 need to really check it either, since handling $zero overwrite is already managed in a single location in the main interpreter loop.
Okay, so it turns out that the (U) version of Infernal Machine *hates* the settings that provide good audio for the (E) version. (I have no clue why I didn't notice this until now.) After a lot of dicking around, I found that AI=540 provided a usable compromise, where the sound is in synch and doesn't crackle like crazy. The problem is that the main menu music is now too fast. None of the other Factor 5 games behave this way.
In an ideal world the (U) version would be placed into a refrigerator and have a small atomic device detonated next to it. Until PJ64 gets proper audio synch or Azimer does something magical, I don't see that version working properly.
This fix isn't quite satisfactory, but with 2200\875, the last 30 seconds or so of the intro have no sound effects, only music. (A bug that could affect other FMVs throughout the game in theory.) 1500\530 has a wee bit of pop and crackle, but the FMVs now work correctly.
warning MSB8030: The linker switch "Minimum Required Version" requires "SubSystem" to be set. Without "SubSystem", the "Minimum Required Version" would not be passed to linker and could prevent to the output binary from running on older Operating Systems.
Do not call glGetError within Glide64::UpdateScreen to check for GL errors generated from Glitch64 functions, as Glitch64 does all the OpenGL handling (even if it is statically linked) and contains code that could be called from a different thread than gfx spec function `UpdateScreen`.
-Disable 32 bit engine for CBFD (E); fixes glitching graphics
-Set VI to 2200 and AI to 500 for smoother gameplay
-Added entry for CBFD Debug Version
-Changed "Conker's Bad Fur Day (ECTS)" to "Conker's Bad Fur Day (U) (ECTS Demo)"
-Added Plugin Notes for CBFD Debug and ECTS
-Make Jabo's D3D config consistent between every version (clear frame, culling, emulate clear, etc...)
The Project64 recompiler is mostly to get games running at full speed for playability, but this is not a game, and implementing memory address range prediction in the recompiler to prevent missing the branch weighs would possibly not be worth it for a demo which should run fast enough with the interpreter.
With these changes, games such as RE2 now use Fixed Audio timing with appropriate VI\AI values, and now have near-perfect audio that will no longer bug out randomly, due to low framerates, or when loading save-states. Infernal Machine no longer has crackling audio. San Francisco Rush 2049 seems improved. Rogue Squadron\Naboo have fixed sound. Tarzan, Rugrats, and other games using Factor 5 tech were adjusted. Some ran fine on vanilla settings for some reason.
I disabled "Start Changed" for Naboo and Infernal Machine, since having it enabled causes significant stuttering in some menus.
FYI, MORT is the name of the speech codec used by Factor 5 games.
I decided on VI=2200 and AI=785 for most titles because those values hit a sweet spot between stopping crackle and keeping sound in synch. (Some games were happy with AI=400.) Some further tweaking might provide better results.
unknown