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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Neroku

Pages: [1]
Graphics / Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« 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.

System / Re: Limitations of repeated key events
« on: August 02, 2020, 03:49:21 pm »
I tested it in a text editor and it gives the exact same results  :(

Good suggestion, I opened a text editor and got exactly the same behavior  ???
It looks then that the limitation isn't introduced by SFML, but it is inherited from the OS just as Laurent said. I wasn't pretty sure what was meant by:

You have the exact same anywhere you can type text.

Know I understand  8). Thank you all  :)

System / Re: Limitations of repeated key events
« on: August 01, 2020, 10:33:17 pm »
no, the problem is the line
else if (event.key.code == sf::Keyboard::B)
by using "else if", this code is going to be executed only if A is NOT pressed. if you want both to be checked, just remove the "else"

I don't think that's the issue. I'm handling a single event per iteration of the for loop, i.e., I'm only pulling one event from the event queue at a time with sf::Window::pollEvent() and there can't be an event whose code member is both A and B at the same time.

System / Re: Limitations of repeated key events
« on: August 01, 2020, 07:35:02 pm »
I would like to know whether or not my assumptions are correct.

So, SFML just maps kind of OS events into their own events.

Graphics / Re: Relationship sf::Texture and sf::Sprite – Flyweight?
« 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

System / Limitations of repeated key events
« on: August 01, 2020, 03:01:54 pm »

I want to rely on the support for event repetition. However, it isn't behaving the way I was expecting. Consider the following program:

#include <SFML/Graphics.hpp>
#include <iostream>

auto main() -> int {
        sf::RenderWindow win(sf::VideoMode(100, 100), "KeyTest");
        while (win.isOpen()) {

                // consume the events
                for (sf::Event event; win.pollEvent(event);)
                        if (event.type == sf::Event::KeyPressed)
                                if (event.key.code == sf::Keyboard::A)
                                        std::cout << "A";
                                else if (event.key.code == sf::Keyboard::B)
                                        std::cout << "B";
                        } else if (event.type == sf::Event::Closed)
                                return 0;

                std::cout << std::flush;

        } // while

With this code, if I press A, then "A" is displayed. If I now press B while still holding A pressed, then "B" is displayed but "A" is no longer displayed (the KeyPressed event for A is no longer generated even though A is still pressed). Finally, if I release B while still holding A pressed, then nothing is printed (no repeated event KeyPressed is generated for A, but is pressed). However, if I released A instead of B, then "B" would have still been printed (the KeyReleased event for A does not affect the repetition of the KeyPress event for B).

My guess is that an event is only repeated if this potential event to be repeated does exactly match the last event that was generated with the same type (i.e., same value in the type data member of the sf::Event).

Graphics / 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):

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

Pages: [1]