All the multiplying and dividing by 100 in controller configs is
messy... An attempted solution to the problem was to not multiply
default_value by 100 in ControllerEmu::ControlGroup::LoadConfig,
but that broke other things instead, so I went with this.
This makes the code cleaner and also leads to some user-visible changes:
The wx game properties will no longer let the user
select WAD languages that don't have any names.
The Qt game list will now display names using the languages
set in the configuration instead of always using
English for PAL GC games and Japanese for WADs.
If a WAD doesn't have a name in the user's preferred language,
English is now selected as a fallback before Japanese.
Boot_BS2Emu was trying to read from the inserted disc even when
nothing was inserted, and this happened to not crash (but not
work either) before VolumeHandler was removed. This commit adds
a check that restores the old behavior, so there is no longer a
crash, but the game ID still doesn't get set for WADs. I don't
know if/how it should be set, so this felt like the safest option.
This was causing a race condition where the "absurdly large aux buffer"
panic alert would be triggered in the last bit of fifo processing on the
CPU thread in deterministic mode (i.e. netplay). SyncGPU is supposed to
move the auxiliary queue data to the beginning of the containing buffer
so we don't have to deal with wraparound; if GpuRunningState is false,
however, it just returns, because it's set to false by another thread -
thus it doesn't know whether RunGpuLoop is still executing (in which
case it can't just reset the pointers, because it may still be using the
buffer) or not (in which case the condition variable it normally waits
for to avoid the previous problem will never be signaled). However,
SyncGPU's caller PushFifoAuxBuffer wasn't aware of this, so if the
buffer was filling at just the right time, it'd stay full and that
function would complain that it was about to overflow it. Similar
problem with ReadDataFromFifoOnCPU afaik. Fix this by returning early
from those as well; other callers of SyncGPU should be safe. A
*slightly* cleaner alternative would be giving the CPU thread a way to
tell when RunGpuLoop has actually exited, but whatever, this works.
