Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Relationship sf::Texture and sf::Sprite – Flyweight?  (Read 327 times)

0 Members and 1 Guest are viewing this topic.

Neroku

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
Relationship sf::Texture and sf::Sprite – Flyweight?
« 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):

Quote
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

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32418
    • View Profile
    • SFML's website
    • Email
Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« Reply #1 on: June 25, 2020, 12:55:14 pm »
I don't know about the pattern, but yes, your description is quite accurate.
Laurent Gomila - SFML developer

Neroku

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« Reply #2 on: August 01, 2020, 03:07:29 pm »
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

Hapax

  • Hero Member
  • *****
  • Posts: 3026
  • My number of posts is shown in hexadecimal.
    • View Profile
Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« Reply #3 on: August 02, 2020, 10:43:10 pm »
Indeed. The pairs can usually be considered equivalent, loosely.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter

Neroku

  • Newbie
  • *
  • Posts: 7
    • View Profile
    • Email
Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« Reply #4 on: August 03, 2020, 08:50:20 pm »
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.

Hapax

  • Hero Member
  • *****
  • Posts: 3026
  • My number of posts is shown in hexadecimal.
    • View Profile
Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« Reply #5 on: August 04, 2020, 02:54:34 pm »
Sorry. I meant that the equivalency was between the pairs, not between its components.
Selba Ward - SFML drawables
Kairos - Timing Library
Rectangular Boundary Collision - Rectangular SAT Collision

@Hapaxiation - Hapaxia on Twitter