These new values are based on the ones that got very good results on Resident Evil 2 with FAT enabled - 1500\530. They mostly play nice with Azimer's, except for Gauntlet Legend. There is sometimes mild crackle with Jabo, but Azimer's tends to cure that.
Infernal Machine (U) now crackles in menus but sounds lovely ingame. Fair enough compromise, IMO. I disabled various self mod methods since they don't seem to be needed.
That Rush 2049 sure does have some lovely MusyX tracks. Turning down the overbearing SFX volume really drives home how good they are.
I also set Hydro Thunder to CF1. Game is much smoother. Timers and boat handling seem fine.
Tried my best to make sure I didn't miss any op-codes. (Ctrl+F searching for "!= 0" and "== 0" throught the file shows me that I didn't.) If I did miss any op-codes, it's no bug, just remaining extra unnecessary checking for zero.
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`.
Lithium64