I'm not really a fan of using the Allman method of braces for typedef's, struct's or other data, but in this case N-Rage seems to have made up his mind throughout 99% the rest of the source to use Allman through it, except only for this particular file. So I guess better to be consistent with the rest.
Miserably hated doing this commit. Couldn't tell which code was whose, which was copyrighted, which was foreign enough to Project64 that I'd probably best just leave-as is, which was even worth considering part of Project64, which cleanups to omit doing and ignore because some ugly practices were rampant throughout the entire file and distracted from the purpose of this pull request too much. So tried to stick to mostly just the braces/indentation changes here.
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.
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`.
Samuel Yuan