Corentin Schreiber

If the PR is merged, or if using a custom build of SFML, the SFML implementation of `vertex_cache` can now be turned on by defining the macro `SFML_HAS_NORMALISED_COORDINATES_VBO` when building...

Commit https://github.com/cschreib/tinyexpr/commit/9de3ed238a2a2d4e669b50b1f6dc159b15e0e951 fixes the issue with ```!!1 != 1```. Thanks to @codeplea for spotting the mistake. This commit also fixes the right-to-left version of TinyExpr (which I had broken badly...

I have considered it, but as per the guidelines set in https://github.com/codeplea/tinyexpr/blob/master/CONTRIBUTING I have opened an issue first to gauge interest. I interpret the subsequent lack of reply as a...

Excellent news! Glad you found it to be an interesting addition.

Of the various options listed above, the least intrusive is probably > RenderStates is extended with a new field specifying the matrix transform to apply to texture coordinates (which gets...

`RenderStates` already holds a matrix for the vertex transformation, so it would be at most a doubling in size. I see what you mean if the only purpose is switching...

I agree. However, unless there is something fundamental about SFML that I missed, this feature does not need to be implemented using the matrix stack. It can start out that...

If I got this right, this is currently handled by ``Texture::bind()``, which create a new matrix on the fly on each bind: https://github.com/SFML/SFML/blob/43b2e9dc125954a40af8a4dc135a6841b4adabb8/src/SFML/Graphics/Texture.cpp#L745-L769 The matrix created here would start off...

Hmm I forgot `Texture::bind` is public, so can't take things out without breaking backward compatibility. Maybe an overload can be added that just binds the texture without setting the matrix.

If this is not your favourite implementation, which alternative would you prefer? A simple flag for normalised vs pixel coordinates in `RenderStates` would probably be the easiest