Pretty much the same as LLE requests, the 'translate' part is chosen. A function is added to the context class to record requests that involves unimplemented HLE functions.
The 'translate' function is a great place to put this in IMO as it is possible to get both untranslated and translated cmdbufs. However a kernel reference has to be passed here, but it is not too hard fortunately.
This class resides in Kernel mainly because that, it's hard for kernel objects to get references to the System (and therefore to the Recorder), while much easier for KernelSystem. If this is to be moved to System the code will likely get much more complex with System (or Recorder) references passed everywhere.
This is for displaying the function name for HLE requests. Probably it is possible to do the same for LLE ones but it would require having the HLE handlers available even when not using them, which doesn't seem to make sense and is more of a hack than a proper solution in my opinion.
Added a new state amiibo_in_range. This state is akin to the real world
physical relationship between a 3DS machine and an amiibo, which is
independent from the service state (or even the machine is powered on or
not). The service state nfc_tag_state is then synchronized with this
physical state on every potential point when the state changes. This
solves the issue where user might load an amiibo before NFC service
initializes, or remove an amiibo after NFC service shutdown, which
previously causes inconsistent state change.
Also removed std::atomic on nfc_tag_state, because
1. It is already protected by g_hle_lock
2. It wasn't properly used in the code anyway. For example, there are
many double loading on this variable, which effectively make it
non-atomic.
Previously, telemetry results couldn't give a good estimate for
performance over time, because it didn't include any fields related to
performance. With this, devs should be able to query metabase for mean
frametime to check for performance regressions after a change is made.
For better tracking of performance regressions on incoming changes, this
change adds a way to dump frametime to file by changing an ini config
option. This is intentionally hidden as its only useful to a small
number of individuals, and not really applicable to the general
userbase.
Cyclical dependencies will result in errors. Redirecting err to null
doesn't help. I removed the redirection so that errors and warnings
would show up (they might be useful for us).
As FFmpeg is added, even more cyclical dependencies are present now. I
do not want to figure out what to install first to fix such things, so I
just decided to ignore all of them with a `0` at the end.
The original purpose of freezing CMake is to use a **higher** version than supplied in order to fix a certain issue. Now that a very long time has passed and mingw's CMake has been updated, there's really no reason to still freeze it any more. What's more, trying to use a certain version is unreliable by pacman's design and will probably cause issues for using older versions of dependencies. The current (and previous) mingw errors may come from this...
Two PBOs are used to speed up pixel copying process. To avoid getting the wrong speed/FPS, a new parameter is added to DrawScreens about whether to increase the frame count.
