This updates the submodule to use 1.68.0. Notably, it gets rid of the
silly
"Info: Boost.Config is older than your compiler version - probably
nothing bad will happen - but you may wish to look for an update Boost
version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this
message."
message that spams the output of the build process on Windows.
Namespaces all OpenGL code under the OpenGL namespace.
Prevents polluting the global namespace and allows clear distinction
between other renderers' code in the future.
The previous form of initializing done here is a C-ism, an empty set of
braces is sufficient for initializing (and doesn't potentially cause
missing brace warnings, given the first member of the struct is a COORD
struct).
Gets rid of the potential for C array-to-pointer decay, and also makes
pointer arithmetic to get the end of the copy range unnecessary. We can
just use std::array's begin() and end() member functions.
LOG_TRACE is only enabled on debug builds which can be quite slow when
trying to debug graphics issues. Instead we can log the messages to the
debug log, which is available on both release and debug builds.
Avoids the need to rebuild multiple source files if the filesystem code
headers change.
This also gets rid of a few instances of indirect inclusions being
relied upon
Avoids the need to rebuild whatever includes the romfs factory header if
the loader header ever changes. We also don't need to include the main
core header. We can instead include the headers we specifically need.
Given these functions aren't intended to be used frequently, there's no
need to keep the std::string instances allocated for the whole lifetime
of the program. It's just a waste of memory.
We have an overload of WriteBuffer that accepts containers that satisfy
the ContiguousContainer concept, which std::array does, so we only need
to pass in the array itself.
ProfileInfo is quite a large struct in terms of data, and we don't need
to perform a copy in these instances, so we can just pass constant
references instead.
We can use the constructor initializer list and just compare the
contained u128's together instead of comparing each element
individually. Ditto for comparing against an invalid UUID.
This is an OpenGL renderer-specific data type. Given that, this type
shouldn't be used within the base interface for the rasterizer. Instead,
we can pass this information to the rasterizer via reference.
Given we use a base-class type within the renderer for the rasterizer
(RasterizerInterface), we want to allow renderers to perform more
complex initialization if they need to do such a thing. This makes it
important to reserve type information.
Given the OpenGL renderer is quite simple settings-wise, this is just a
simple shuffling of the initialization code. For something like Vulkan
however this might involve doing something like:
// Initialize and call rasterizer-specific function that requires
// the full type of the instance created.
auto raster = std::make_unique<VulkanRasterizer>(some, params);
raster->CallSomeVulkanRasterizerSpecificFunction();
// Assign to base class variable
rasterizer = std::move(raster)
Moving a const reference isn't possible, so this just results in a copy
(and given ProfileInfo is composed of trivial types and aggregates, a
move wouldn't really do anything).
Prevents potentially making copies or doing silly things by accident
with the System instance, particularly given our current core is
designed (unfortunately) around one instantiable instance.
This will prevent the accidental case of:
auto instance = System::Instance();
being compiled without warning when it's supposed to be:
auto& instance = System::Instance();
Allows querying the inverse of IsDomain() to make things more readable.
This will likely also be usable in the event of implementing
ConvertDomainToSession().
We can make the enum class type compatible with fmt by providing an
overload of operator<<.
While we're at it, perform proper bounds checking. If something exceeds
the array, it should be a hard fail, because it's, without a doubt, a
programmer error in this case.
Many of these aren't necessary and will cause this file to be required
to be recompiled whenever any changes to those files are made, which
lengthens compile times for no reason.
This also removes an unused metadata variable from AppLoader_XCI
Using LOG_TRACE here isn't a good idea because LOG_TRACE is only enabled
when yuzu is compiled in debug mode. Debug mode is also quite slow, and
so we're potentially throwing away logging messages that can provide
value when trying to boot games.
The thread field serves to indicate which thread a log is related to and
provides the length of the thread's name, so we can print that out,
ditto for modules.
Now we can know what threads are potentially spawning off logging
messages (for example Lydie & Suelle bounces between MainThread and
LoadingThread when initializing the game).
Previously core itself was the library containing the code to gather
common information (build info, CPU info, and OS info), however all of
this isn't core-dependent and can be moved to the common code and use
the common interfaces. We can then just call those functions from the
core instead.
This will allow replacing our CPU detection with Xbyak's which has
better detection facilities than ours. It also keeps more
architecture-dependent code in common instead of core.
These currently aren't used and contain commented out source code that
corresponds to Dolphin's JIT. Given our CPU code is organized quite
differently, we shouldn't be keeping this around (at the moment it just
adds to compile times marginally).
The filter is returned via const reference, so this was making a
pointless copy of the entire filter every time a message was being
pushed into the logger instance.
Despite being covered by a global mutex, we should still ensure that the
class handles its reference counts properly. This avoids potential
shenanigans when it comes to data races.
Given this is the root object that drives quite a bit of the kernel
object hierarchy, ensuring we always have the correct behavior (and no
races) is a good thing.
struct should be used when the data type is very simple or otherwise has
no invariants associated with it. Given these are used to form a
hierarchy, class should be used instead.
Previously these were being unused (or partially unused). While we're at
it, use better naming to make it visibly obvious which variant of the
path is being used.
Previously this would warn of truncating a std::size_t to a u32. This is
safe because we'll obviously never have more than UINT32_MAX amount of
uniform buffers.
Instead, we make a struct for renderer settings and allow the renderer
to update all of these settings, getting rid of the need for
global-scoped variables.
This also uncovered a few indirect inclusions for certain headers, which
this commit also fixes.
This is simply copied by value, so there's no need to make it a
modifiable reference.
While we're at it, make the names of the parameters match its
definition.
It's generally easier to follow code using conditionals that operate in
terms of the true case followed by the false case (no chance of
overlooking the exclamation mark).
resize() causes the vector to expand and zero out the added members to
the vector, however we can avoid this zeroing by using assign().
Given we have the pointer to the data we want to copy, we can calculate
the end pointer and directly copy the range of data without the
need to perform the resize() beforehand.
The current way were doing it would require copying a 768 character
buffer (part of the Entry struct) to the new element in the vector.
Given it's a plain array, std::move won't eliminate that.
Instead, we can emplace an instance directly into the destination buffer
and then fill it out, avoiding the need to perform any unnecessary
copies.
Given this is done in a loop, we can request the destination to allocate
all of the necessary memory ahead of time, avoiding the need to
potentially keep reallocating over and over on every few insertions into
the vector.
Lioncash