* yuzu/bootmanager: Remove unnecessary pointer casts
We can just invoke these functions by qualifying the object name before
the function.
* yuzu/bootmanager: unsigned -> u32
Same thing (for platforms we support), less reading.
* yuzu/bootmanager: Default EmuThread's destructor in the cpp file
This class contains non-trivial members, so we should default the
destructor's definition within the cpp file.
* yuzu/bootmanager: Treat the resolution factor as a u32
Treating it as a u16 can result in a sign-conversion warning when
performing arithmetic with it, as u16 promotes to an int when aritmetic
is performed on it, not unsigned int.
This also makes the interface more uniform, as the layout interface now
operates on u32 across the board.
* yuzu/bootmanager: Log out screenshot destination path
We can make this message more meaningful by indicating the location the
screenshot has been saved to. We can also log out whenever a screenshot
could not be saved (e.g. due to filesystem permissions or some other
reason).
* Fix compilation
This allows an IPS patch to edit .bss. This is useful for game patches
that need to add code, as putting things in .bss allows adding new code
*without* editing .code and thus without having to relocate everything.
Previously we were building with MBCS, which is pretty undesirable. We
want the application to be Unicode-aware in general.
Currently, we make the command line variant of yuzu use ANSI variants of
the non-standard getopt functions that we link in for Windows, given we
only have an ANSI option-set.
We should really replace getopt with a library that we make all build
types of yuzu link in, but this will have to do for the time being.
Enforces the use of the proper URL resolution functions. e.g.
url = some_local_path_string;
should actually be:
url = QUrl::fromLocalPath(some_local_path_string);
etc.
This makes it harder to cause bugs when operating with both strings and
URLs at the same time.
Other overloads of start() are considerably much safer to use if we ever
need this in the future and need to pass arguments to the program, given
it contains separate parameters for the program path and the arguments
themselves, whereas this unsafe overload contains both as a single
string.
Given the alternatives are much safer, we can disable this.
Currently, having a replacement code.bin causes Citra to crash as it is
trying to load icon data from code.bin because of a typo. This commit
fixes that typo.
This attempts to fix segfault in some tests where page table is set before initializing cpu core (intended behaviour? might be worth a check...)
see: src/tests/core/arm/arm_test_common.cpp
see: src/tests/core/arm/dyncom/arm_dyncom_vfp_tests.cpp
It will both change the page table in memory and notify the CPU about the change by itself. This way there is no need to call memory.SetCurrentPageTable() when kernel.setCurrentProcess() and the management is kept internally in the kernel
By default, MSVC doesn't use standards-compliant volatile semantics.
This makes it behave in a standards-compliant manner, making
expectations more uniform across compilers.
The C++ standard allows constexpr variables declared with the extern
keyword to have external linkage. Previously MSVC wasn't abiding by
this. This just makes the compiler more standards compliant during
builds.
Given we currently don't make use of anything that would break by this,
this is safe to enable.
This is performing more work than would otherwise be necessary during
VMManager's destruction. All we actually want to occur in this scenario
is for any allocated memory to be freed, which will happen automatically
as the VMManager instance goes out of scope.
Anything else being done is simply unnecessary work.
This makes cpu_core and memory being completely independent components inside the system, having a simpler and more understandable initialization process
The thread which casues page table changes in memory will be responsible to notify the cpu_core too
* CMakeLists: Move compilation flags into the src directory
We generally shouldn't be hijacking CMAKE_CXX_FLAGS, etc as a means to
append flags to the targets, since this adds the compilation flags to
everything, including our externals, which can result in weird issues
and makes the build hierarchy fragile.
Instead, we want to just apply these compilation flags to our targets,
and let those managing external libraries to properly specify their
compilation flags.
This also results in us not getting as many warnings, as we don't raise
the warning level on every external target.
* CMakeLists: Move off of modifying CMAKE_*-related flags
Modifying CMAKE_* related flags directly applies those changes to every
single CMake target. This includes even the targets we have in the
externals directory.
So, if we ever increased our warning levels, or enabled particular ones,
or enabled any other compilation setting, then this would apply to
externals as well, which is often not desirable.
This makes our compilation flag setup less error prone by only applying
our settings to our targets and leaving the externals alone entirely.
This also means we don't end up clobbering any provided flags on the
command line either, allowing users to specifically use the flags they
want.
