binary1248

From an IETF perspective there is no such thing as an "invalid IP address". All 2^32 distinct values for v4 and all 2^128 distinct values for v6 always represent an...

SFML has always been rather conservative with language feature usage. It only took *searches through discussion history* ... many ... years for us to make the switch to "modern C++"...

I also don't have anything against making the API more accessible to a wider audience as long as we don't have to sacrifice the core value of the library being...

Passing an entire matrix is a bit too heavy for me. In 99% of all use cases, the user is either going to use either pixel or normalized coordinates. And...

The OpenGL matrix stack has been deprecated for more than a decade and even removed from the core profile (and newer OpenGL ES). We shouldn't encourage users to make use...

Assuming we added a texture matrix to `RenderStates` how would it interact with the current texture matrix manipulation that SFML performs? There would have to be some way to indicate...

I think the use case you mentioned above about texture atlases is already typically implemented with pre-computed texture coordinates (pixel coordinates makes this pretty simple). The key to performance is...

Adding the flag to `RenderStates` makes more sense. `RenderStates` are meant to be copied around and possibly reused. Adding the flag to `sf::Texture` would just hinder the user from using...

Since setting this socket option depends on the concrete use case, it would be something that SFML optionally allows the developer to activate via a member function.

I can understand the dilemma here. Basically, because libraries want to be as nice to use as possible for users they don't want to force the user to have to...