SFML community forums
Help => Graphics => Topic started by: Neroku on June 25, 2020, 12:13:19 pm
-
Hello all :)
I was struggling to understand how sf::Texture and sf::Sprite relate to each other. At first, I thought that an sf::Sprite object was a proxy object that stands for an sf::Texture, i.e., The Proxy Pattern. However, after reading the following in the documentation (https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Sprite.php (https://www.sfml-dev.org/documentation/2.5.1/classsf_1_1Sprite.php)):
The separation of sf::Sprite and sf::Texture allows more flexibility and better performances: indeed an sf::Texture is a heavy resource, and any operation on it is slow (often too slow for real-time applications). On the other side, an sf::Sprite is a lightweight object which can use the pixel data of an sf::Texture and draw it with its own transformation/color/blending attributes.
The quote above definitely reminds me of The Flyweight Pattern. That is, many sf::Sprite objects may refer to the same sf::Texture object and they may only store information that is specific to a particular sf::Sprite object itself, as opposed to the sf::Texture object. For example, the sf::Sprite object may contain the position where to display the texture, rotation, scale, etc.
Am I right about the pattern followed for implementing the relationship between sf::Texture and sf::Sprite objects???
Thanks in Advance :D
-
I don't know about the pattern, but yes, your description is quite accurate.
-
By the way, it's not just sf::Sprite and sf::Texture. I've found that there are other pairs of classes that follow the Flyweight pattern as well:
- sf::Text and sf::Font
- sf::Sound and sf::SoundBuffer
-
Indeed. The pairs can usually be considered equivalent, loosely.
-
Indeed. The pairs can usually be considered equivalent, loosely.
Regarding the pairs:
- sf::Sprite – sf::Texture
- sf::Text – sf::Font
- sf::Sound – sf::SoundBuffer
I wouldn't say that the elements the pairs are made up are equivalent, but they are halves of an entity. That is, a pair, as a whole (e.g., sf::Sound + sf::SoundBuffer), forms an entity to represent (e.g., the sound). The latter contains the bare-bone resource, whereas the former contains the properties specific to the entity (e.g., position in time to play the sound) – which is a flyweight object. These entities are split into two halves for purely efficiency reasons: saving memory.
-
Sorry. I meant that the equivalency was between the pairs, not between its components.