Texture equality operator

[coolnonis]

Hey guys, I was just wondering if there's a specific reason that an equality operator is not implemented for the sf::Texture class. I'm currently writing an OpenGL sprite batcher using sfml textures, but i'd like to implement automatic texture switching.

Is there a reason I shouldn't re-implement the texture class to support the comparison of 2 objects using the internal m_texture ID?

[eXpl0it3r]

Not fully sure why, but an equality operator for sf::Texture could have multiple meanings. For example whether it's the same OpenGL resource, or whether it's the same pixels, or ...
Thus having an equality operator would make things a bit ambiguous, which is what we like to prevent (hence the Simple in SFML). Next to that, it's really rather easy to keep track of of textures on your own (even though it might be harder for your layout).

Then again, I'm just some guy here, let the big people speak for themselves.

[binary1248]

So... how would you define this operator to take into account that textures with the same GL name (ID) can exist in different contexts? Just wondering... 

[coolnonis]

Not fully sure why, but an equality operator for sf::Texture could have multiple meanings. For example whether it's the same OpenGL resource, or whether it's the same pixels, or ...

I see. Thank you for the swift reply.

In my case, I want to check the equality between two textures in regards to their OpenGL texture ID.

Maybe this will do:

namespace sf
{

bool Texture::operator==(const Texture& other)
{
return (this->m_texture == other.m_texture);
}

}
 

[FRex]

About the same issue: I wish SFML would let us get the m_cacheID(not the GL ID, the internal SFML 64 bit ID), now it's private and RenderTexture/Window are friends. Why not let user get the cache ID too?

[coolnonis]

About the same issue: I wish SFML would let us get the m_cacheID(not the GL ID, the internal SFML 64 bit ID), now it's private and RenderTexture/Window are friends. Why not let user get the cache ID too?

Sort of related, do you think I should use the SFML cache ID rather than the GL ID?

Looking at the source code, It looks like the use of the assignment operator causes the object to generate a new cacheID for itself.

Texture& Texture::operator =(const Texture& right)
{
    Texture temp(right);

    std::swap(m_size, temp.m_size);
    std::swap(m_actualSize, temp.m_actualSize);
    std::swap(m_texture, temp.m_texture);
    std::swap(m_isSmooth, temp.m_isSmooth);
    std::swap(m_isRepeated, temp.m_isRepeated);
    std::swap(m_pixelsFlipped, temp.m_pixelsFlipped);
    // New cache ID
    m_cacheId = getUniqueId();

    return *this;
}

I assume that would make it difficult to compare texture equality.

Also, i'm not quite sure if you were being sarcastic there... 

[FRex]

No, I really dislike how airtight SFML is about some things and how it might get in the way, SFML uses that ID for it's own cache, on each copy, load and construction it gets changed so it's always unique, there is really no reason why SFML wouldn't give it to us but it just doesn't...

[Laurent]

This ID is purely an implementation detail. I have no idea what it would mean if it appeared in a public API... Moreover, since it was added to implement an internal optimization, I may perfectly drop it one day, if the optimization strategy changes, or if I find bugs related to it.

Regarding Texture::operator=, yes it could have different meanings, so it's not trivial and should be left to the user. Don't forget that you can get (almost) everything that you want about (almost) any OpenGL object with glGetXxx calls. Including the ID of the currently bound texture. If you're afraid to call glGet at runtime, call it once after the creation of the texture and store it for later use.

[coolnonis]

Thanks for the advice everyone.

I've decided to re-implement my sprite batcher to use shared_ptr address comparisons to check the equality of textures. It works well with my current implementation.

I feel that this is a better solution than modifying the SFML source, which would cause issues if the internal structure of the Texture class was changed.