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.


Topics - Neroku

Pages: [1]
1
System / Limitations of repeated key events
« on: August 01, 2020, 03:01:54 pm »
Hello,

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");
        win.setFramerateLimit(8);
        win.setKeyRepeatEnabled(true);
       
        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).

2
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):

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

Pages: [1]