Now that we have an actual interface to manage things, we can stop
duplicating the calls to to the pixel shader manager and remove the
need to remember to actually do so when disabling or enabling the
bounding box.
Rather than expose the bounding box members directly, we can instead
provide an interface for code to use. This makes it nicer to transition
from global data, as the interface function names are already in
place.
Now that we've extracted all of the stateless functions that can be
hidden, it's time to make the index generator a regular class with
active data members.
This can just be a member that sits within the vertex manager base
class. By deglobalizing the state of the index generator we also get rid
of the wonky dual-initializing that was going on within the OpenGL
backend.
Since the renderer is always initialized before the vertex manager, we
now only call Init() once throughout the execution lifecycle.
We can use if constexpr with the template functions that pass in a
non-type template parameter, allowing the removal of branches that
aren't taken at compile time.
Compilers will generally do this by default, however, we now give a
gentle prodding to the compiler if this would otherwise not be the case.
These don't rely on any of the static members within the IndexGenerator
class, so we can make all of these functions fully internal to the
translation unit.
We can make use of if constexpr in several scenarios here to allow
compilers to exise the relevant code paths out.
Technically a decent compiler would do this already, but now we can give
compilers a little more nudging here in the event that isn't the case.
cmd2 is a u32, so any bitwise arithmetic on it with a type of the same
size or smaller will result in a u32 value. This is also implicitly
converted to an unsigned type in the if statement as well, given that
size_t * int -> size_t.
This is just more explicit about the operations occurring and also
likely silences a sign conversion warning.
We only use these string streams to output into a final std::string
instance, we don't read into types with them. Because of this, we can
just make use of std::ostringstream, rather than the fully-fledged
std::stringstream.
No behavioral change. This is intended to make the transition to fmt
less noisy in subsequent changes by combining insertions of multiple
string literals into one where applicable.
Begins the conversion of the shader generators over to using fmt
formatting specifiers.
This also has a benefit over the older StringFromFormat-based API in
that all formatted data is appended to the existing buffer rather than
creating a completely separate string and then appending it to the
internal string buffer.
Previously the logging was a in a little bit of a disarray. Some things
were in namespaces, and other things were not.
Given this code will feature a bit of restructuring during the
transition over to fmt, this is a good time to unify it under a single
namespace and also remove functions and types from the global namespace.
Now, all functions and types are under the Common::Log namespace. The
only outliers being, of course, the preprocessor macros.
Continues the migration to using fmt.
Notably, this allows safely converting a map within USBUtils over to
containing string view instances, rather than std::string instances, as
fmt safely handles the formatting of string views.
Migrates most of VideoCommon over to using fmt, with the exception being
the shader generator code. The shader generators are quite large and
have more corner cases to deal with in terms of conversion (shaders have
braces in them, so we need to make sure to escape them).
Because of the large amount of code that would need to be converted, the
conversion of VideoCommon will be in two parts:
- This change (which converts over the general case string formatting),
- A follow up change that will specifically deal with converting over
the shader generators.
Provides the same semantics of a C array, but is much nicer to work
with.
Notably, it makes all cases of performing comparisons with said arrays
significantly less reading-involved.
Trims out unnecessary includes to avoid unnecessary header dependencies.
This also resolves indirect inclusions of <optional> within
IMUAccelerometer.h and IMUGyroscope.h
Given all conditional bodies only contain a return, the use of else here
isn't necessary.
This has the benefit of consistently vertically aligning the names.
This variable isn't std::moved anywhere and is just read out of into a
string. Instead of making a copy, and then another copy of the data into
a std::string, we can take it by reference, only copying the data once.
This isn't std::moved wholesale into a member variable or further
std::moved into another function, so it's better to take it by const
reference here to avoid unnecessary reallocations of contained
std::string instances.
Moves it closer to where its used, narrowing its visible scope, as well
as preventing unnecessary std::string constructor executions in the
event invalid data is encountered (the continue branch).
std::function is allowed to heap allocate in order to store captured
variables, etc, so std::function isn't a trivial type. We can std::move
here in order to avoid potential reallocating.
While we're at it, make the definition's parameter name match the
declaration's parameter name for consistency.
If the parameter is const, then a move won't actually be able to occur,
making the std::move non-functional. We can remove the const qualifier
to remedy this.
PARTITION_NONE technically has a runtime static constructor otherwise.
This allows compile-time instances of Partition to be created without
the use of a static constructor.
Introduced in a995e2f5ba
We need to be performing a bitwise AND on the flags and not a logical
AND, otherwise we could end up counting device objects that don't
support forced feedback.
Makes it a little more explicit which dialog outcomes we're expecting.
While we're at it, we can invert them into guard clauses to unindent
code a little bit.
Avoids propagating headers into scopes where they're not necessary.
Also uncovered reliance on an indirect inclusion within
CheatsManager.cpp, which is now fixed.
If a user indicates that they want to clone and edit an AR code, then
click cancel on the following dialog, we shouldn't actually clone the
code.
We also shouldn't resave the codes if the edit dialog is opened and then
closed again via cancel, as there's nothing that actually changed. This
way we don't perform disk accesses unless they're actually necessary.
Previously, the constructor of GameConfigEdit wasn't doing anything with
the passed in parent pointer. This is dangerous because it can result in
memory being leaked in certain scenarios. It can also affect layout
decisions made by the parent. Instead, pass it through to the base class.
Current usages of the class pass in nullptr as the parent, so this is a
safe change to make with regards to the class hierarchy.
While we're at it, we can std::move the passed in QString into the class
member, allowing calling code to move strings into the constructor,
avoiding copies.
QStringLiterals generate a buffer so that during runtime there's very
little cost to constructing a QString. However, this also means that
duplicated strings cannot be optimized out into a single entry that gets
referenced everywhere, taking up space in the binary.
Rather than use QStringLiteral(""), we can just use QString{} (the
default constructor) to signify the empty string. This gets rid of an
unnecessary string buffer from being created, saving a tiny bit of
space.
While we're at it, we can just use the character overloads of particular
functions when they're available instead of using a QString overload.
The characters in this case are Latin-1 to begin with, so we can just
specify the characters as QLatin1Char instances to use those overloads.
These will automatically convert to QChar if needed, so this is safe.
AddMessage() by itself doesn't perform string formatting facilities, so
this message was actually using the EFB scale as a duration value, not a
format argument. This corrects that.
Same behavior without hardcoding the type of the mutex within the lock
guards. This means the type of the mutex would be able to be changed
without needing to also change all occurrences lock guards are used.
Lioncash