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.
Ensures both operands have the same sign in the comparison.
While we're at it, we can get rid of the redundant casting of ub_size to
an int. This type will always be trivial and alias a built-in type (not
doing so would break backwards compatibility at a standard level).
All calling code assumes that the rasterizer will be in a valid state,
which is a totally fine assumption. The only way the rasterizer wouldn't
be is if initialization is done incorrectly or fails, which is checked
against in System::Init().
We move the initialization of the renderer to the core class, while
keeping the creation of it and any other specifics in video_core. This
way we can ensure that the renderer is initialized and doesn't give
unfettered access to the renderer. This also makes dependencies on types
more explicit.
For example, the GPU class doesn't need to depend on the
existence of a renderer, it only needs to care about whether or not it
has a rasterizer, but since it was accessing the global variable, it was
also making the renderer a part of its dependency chain. By adjusting
the interface, we can get rid of this dependency.
Avoids performing unnecessary copies of 65560 byte sized ShaderSetup
instances, considering it's only used as part of lookup and not
modified.
Given the parameters were already const, it's likely taking these
parameters by reference was intended but the ampersand was forgotten.
Makes the global a member of the RendererBase class. We also change this
to be a reference. Passing any form of null pointer to these functions
is incorrect entirely, especially given the code itself assumes that the
pointer would always be in a valid state.
This also makes it easier to follow the lifecycle of instances being
used, as we explicitly interact the renderer with the rasterizer, rather
than it just operating on a global pointer.
bunnei