CMake supports a number of strings for truthy and falsey values.
ON/OFF and TRUE/FALSE are the most popular but 1/0 is also supported.
This is mostly a style choice but I'm inclined to believe that ON/OFF
is the most popular option and I'm generally in favor of style
choices that better align with the community at large.
As a rule of thumb, if the type is less than or equal to the CPU
register width times two then you ought to pass it by value. This
will lead to more efficient code generation.
Because the sf::Texture::m_texture value changes when the texture is
reloaded from disk, we need to rebind the texture since the previously
bound sf::Texture::m_texture value is no longer a valid identifier.
Similar renaming for Font::loadFromMemory and Font::loadFromStream.
The goal is to better express the need to keep the source available,
similar to Music::openFromFile for example.
This example is optional since it may be skipped on hardware where
geometry shaders are not supported. The way I rewrote it in 7234fc1
resulted in the shader still being attempted to be loaded even when
geometry shaders were not supported leading to the whole program
crashing.
My bad.
This new API is built on top of std::variant. This allows us to
store many different event types in a space-efficient way and access
the active event type in a type-safe manner that eliminates the
categories of UB that are possible with unions.
Co-authored-by: kimci86 <kimci86@hotmail.fr>
This change was made in 359fe90 due to recommendations from tooling.
On its face this change makes sense since it removes a copy that
isn't always necessary. In practice it caused ergonomic issues due
to now being forced to make a copy of the render states when needed.
The performance gains of eliding this copy are unsubstantiated. We
have not done any profiling to measure its impact. For lack of such
measurements I'd rather err on the side of improved user experience.
If future benchmarks prove this copy is rather expensive then we
can reconsider removing it with that evidence in mind.
While I don't suspect there are any uninitialize variable bugs
present, it's still good to err on the side of safety and provide
an initial value nonetheless.
