"Use high-level-emulated audio" does make sense, but seems a tad bit strong (and people could mistake the "high level" to mean extra/better emulation without any scientific HLE understanding). So I think "Audio HLE" looks better.
Either say "Percentage", or just drop the '%' since this symbol of unit is not relevant to what the menu item should convey to the user. What we're really trying to do is show the CPU usage statistics...most likely the users would see for themselves what unit it comes out as (percentage, fraction, whatever).
"On" is a preposition shorter than 5 letters long. Standard title case does not ever capitalize short prepositions (unless they are the very first word of the title, then usually). You can see this logic in the Visual Studio 2008 IDE itself: It has menu items such as "Attach to Process" and "Find[/Replace] in Files", in which the prepositions "to" and "in" are, correctly so, not capitalized by Microsoft in the VS2008 menus.
After some testing, I've concluded that software depth is better on by default than off. Testing every single game would be too time consuming, and the problems it fixes can be obscure. Enabling FB by default just seems like good sense. A few games need it disabled, but I'll fix them case-by-case.
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`.
- Installer.iss: Removed a non longer maintained input plugin.
- package_zip.bat: Output directory will be cleaned before start to copy
files, also removed copy line for two .chm files that are outdated.
- Added few Desc where missing.
- Added a Missing String in English main lang file.
- Fixed some typos in the original english strings.
- Removed few Unused Strings.
- Sorted Strings by IDs.
unknown