Messages

1

General discussions / Re: SFML Game Development -- A book on SFML

« on: April 17, 2016, 06:29:50 pm »

I don’t know if it’s a problem, but having classes like ButtonContainer and TextBoxContainer (and more) aside classes Button and TextBox (and more) seems like defeating the purpose of the original idea of a generic class Container. After all, the only need is to pack widgets of a same type and same functional group together, no more no less (and getting rid of lots of range-based for loops).
But it looks like I found my way with… lambdas. The lambda is given pointers to various widgets, and is stored inside one widget through std::function (like I had been doing so far with buttons executing code when clicked), before packing said widget into a container… a generic container. Now I don’t need to read some variable deep inside the component hierarchy and therefore I don’t need specific methods fulfilling this need; instead the std::function is executed when a certain event reaches and activates the widget.
Lambdas appear to be the foundation of my technical design, they blossom everywhere.

2

General discussions / Re: SFML Game Development -- A book on SFML

« on: April 16, 2016, 02:02:39 pm »

If I’m not mistaken, the class Button is the only class whose instances are actually packed into containers of class Container, which holds Components together. If you had to pack a set of Components other than Buttons (say Text boxes eg.) in another Container instance, how would you proceed? The problem is that this other class would need specific methods to work with (like reading input text), not needed by nor working with Buttons.
One solution would be to create sub-classes of Container, one for each type of widget, but it feels like adding way too many classes. Any other solution?

3

Window / Re: Maximize window: order of events

« on: March 31, 2016, 06:27:23 pm »

You can see that case in many other applications, most likely unrelated to the order of events. I personally am not surprised when I change the window size and then don't move my mouse, that some hover effect is not being executed and I doubt that this is just my feeling.
I mean if you think about it, does it break anything? Can you first try and implement anything else or is this the last thing you need to get working?

In the end there's no much SFML can do about this. Delaying events to check for other events is just not an option. Since you're on Linux, what WM do you use? Maybe it's a WM bug?

The application will work fine because it’s a corner case. I guess I could call that function updateHovered() when sf::Event::Resized is fired as well, but I feel it would just be a hack not worth the hassle.

I use MATE, so the WM is called Marco (fork from GNOME’s Metacity). Maybe asking them about it could solve the issue, I will think about it.

Anyway, thank you for clearing that up.

4

Window / Re: Maximize window: order of events

« on: March 31, 2016, 04:27:38 pm »

If I remember correctly, SFML just provides events in the order as they are provided by the OS.

I hope it does in principle. Would this mean that the OS sends these events in reverse order in some cases?
What about other platforms than Linux, can anyone using Windows or OSX test this issue?

So this size/position mismatch goes for how long? One frame? Half a frame?
I think every user can deal with possibility of some 16ms artifact when changing the window size.

In the use case described above, where the object is not set to hovered state despite being covered by the mouse, the problem lasts… as long as you don’t move the mouse essentially. Otherwise it gets back to normal of course. We could always argue that the user can just move the mouse in his momentum of resizing the window and be done with it, but I feel like the underlying process is not correct.

Why do you call sf::Mouse::getPosition() when dealing with a mouse event? The mouse event already provides the mouse coordinates.

Of course, I just use it it for the purpose of my test, and otherwise for event types that have no data.

5

Window / Re: Maximize window: order of events

« on: March 31, 2016, 12:35:43 pm »

And why is it a problem?

As I said, it looks like it is inconsistent by itself. But I did not stumble on this issue on purpose.
In the game I am working on, during the processEvent phase, I forward every event (except sf::Event::Closed and sf::Event::Resized) to every object that is supposed to be interested. Inside the object, for each type of event, I retrieve useful information from the event. Eg. for sf::Event::MouseEntered:

const auto& mousePosition = renderWindow.mapPixelToCoords(sf::Mouse::getPosition(renderWindow));

This information is immediately copied into the target of a std::function, that is to be executed later on, typically during the update phase. Eg.:

pendingUpdate = [this, mousePosition] ()
{
        updateHovered(mousePosition);
};

In the case of sf::Event::MouseEntered being fired first, the function updateHovered() does not work properly, ie. the object is not hovered despite the mouse being on top of it when that is the case after window resizing.

I did additional tests, to print the value of sf::Mouse::getPosition(renderWindow) for each event:

• When sf::Event::Resized is fired first, sf::Mouse::getPosition(renderWindow) gives the new value immediately, which is correct.
• When sf::Event::MouseEntered is fired first, sf::Mouse::getPosition(renderWindow) gives the new value immediately as well (before sf::Event::Resized being polled). This looks fine because another value would make no sense. But at this point, this value is mapPixelToCoords’ed, which stores coordinates relative to the old window size, ie. x and y are unchanged after mapPixelToCoords(), like they would be with the old window state (view not stretched). So there is a mix of the old and the new happening here, which is not a good thing.

I hope I am clear enough; I can provide a full use case with figures if there is a need for a better explanation.

Btw I forgot to mention my environment in the OP: Debian GNU/Linux 8 amd64.

Updated code to check the explained behaviour:

#include <iostream>

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow(sf::VideoMode(800, 700), "Test event Resized");
        renderWindow.setFramerateLimit(60);
        std::cout << "[init] renderWindow.getPosition(): " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
       
        while (renderWindow.isOpen())
        {
                sf::Event event;
                while (renderWindow.pollEvent(event))
                {
                        std::cout << "event.type = " << event.type << std::endl;
                        std::cout << "sf::Mouse::getPosition(renderWindow) = " << sf::Mouse::getPosition(renderWindow).x << ", " << sf::Mouse::getPosition(renderWindow).y << std::endl;
                        switch (event.type)
                        {
                                case sf::Event::Closed :
                                {
                                        renderWindow.close();
                                }
                                break;
                               
                                case sf::Event::Resized :
                                {
                                        std::cout << "[sf::Event::Resized] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                }
                                break;
                               
                                case sf::Event::GainedFocus :
                                {
                                        std::cout << "[sf::Event::GainedFocus] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                }
                                break;
                               
                                case sf::Event::MouseEntered :
                                {
                                        std::cout << "[sf::Event::MouseEntered] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                        std::cout << "[sf::Event::MouseEntered] renderWindow.mapPixelToCoords(sf::Mouse::getPosition(renderWindow)) = " << renderWindow.mapPixelToCoords(sf::Mouse::getPosition(renderWindow)).x << ", " << renderWindow.mapPixelToCoords(sf::Mouse::getPosition(renderWindow)).y << std::endl;
                                }
                                break;
                               
                                default :
                                break;
                        }
                }
               
                renderWindow.clear();
                renderWindow.display();
        }
       
        return 0;
}

6

Window / Maximize window: order of events

« on: March 31, 2016, 12:58:02 am »

In the context of a SFML window not covering all the screen, when I maximize it, the mouse pointer typically enters the now maximized window. I get two events reflecting this: sf::Event::Resized and sf::Event::MouseEntered, in this order. In some cases, the order is reversed and I get sf::Event::MouseEntered before sf::Event::Resized. I have not been able to find out why, but moving the window beforehand can apparently change the result; somehow having the window positioned to the left of around 40 pixels (even left of 0) triggers the incorrect order.
My understanding is that sf::Event::Resized should always be fired before sf::Event::MouseEntered.
This has been tested with SFML 2.3.2, and I have not found any commit, issue or PR posterior to that version mentioning this issue on GitHub.

Minimal example:

#include <iostream>

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow renderWindow(sf::VideoMode(800, 700), "Test event Resized");
        renderWindow.setFramerateLimit(60);
        std::cout << "[init] renderWindow.getPosition(): " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
       
        while (renderWindow.isOpen())
        {
                sf::Event event;
                while (renderWindow.pollEvent(event))
                {
                        std::cout << "event.type = " << event.type << std::endl;
                        switch (event.type)
                        {
                                case sf::Event::Closed :
                                {
                                        renderWindow.close();
                                }
                                break;
                               
                                case sf::Event::Resized :
                                {
                                        std::cout << "[sf::Event::Resized] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                }
                                break;
                               
                                case sf::Event::GainedFocus :
                                {
                                        std::cout << "[sf::Event::GainedFocus] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                }
                                break;
                               
                                case sf::Event::MouseEntered :
                                {
                                        std::cout << "[sf::Event::MouseEntered] renderWindow.getPosition() = " << renderWindow.getPosition().x << ", " << renderWindow.getPosition().y << std::endl;
                                }
                                break;
                               
                                default :
                                break;
                        }
                }
               
                renderWindow.clear();
                renderWindow.display();
        }
       
        return 0;
}
 

7

General discussions / Re: AW: SFML Game Development -- A book on SFML

« on: June 20, 2014, 10:24:18 am »

The question is: What does it matter to you, if you can't even verify it yourself.

Besides that principals are there to give a good orientation and should not be forced on to everything. Use it where it makes sense, adjust it where needed.

It could matter to me because I am interested in applying good design from the start. If I am told that, yes, this principle and that principle are applied in the book, in this concept and that concept, I know I can then look up myself. The good thing about it is that we have both clear explanations from the book and access to the source code for implementation details. So I'd be able to learn about such advanced topics more easily.
BTW my goal is not to copy and paste source code into my own project. I want to understand topics and put what I can get from that into my own code.

8

General discussions / Re: SFML Game Development -- A book on SFML

« on: June 19, 2014, 01:03:41 pm »

Is the source code from the book applying all the principles of SOLID design? Namely what is found here: http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29.
I have not checked myself because I am not skilled enough. Examples of what could be such designs are the scene graph and the command system, but it is just a guess.

9

General discussions / Re: SFML 3 - What is your vision?

« on: April 30, 2014, 06:00:09 pm »

Until you realize that there would be not any clean solution for the text object to know if the reference it points at has changed its string and internal states need to be updated.

That is what I thought, more or less. Until very recently I had a utility struct acting as a wrapper on top of sf::Text, which also held a container of sf::String*. The idea was to give the needed strings to the Text instance once, and then forget about them. But even this way, whenever the language changed, I had to do myOwnText::update(), with no argument, so as to apply sf::Text::setString() internally.
I got rid of myOwnText today, and now only rely on sf::Text again and store the needed strings case by case.

10

General discussions / Re: SFML 3 - What is your vision?

« on: April 30, 2014, 05:16:01 pm »

An issue I am dealing with in my own project:
The application allows the user to switch language on the fly in a settings screen. Most sf::Text instances display some text in the current language. Whenever the language is changed, all of these instances have to apply the sf::Text::setString() method with the reference to the new localized string. Said string, a sf::String, is always at the same address, stored in a std::map.
Would it be possible to let a sf::Text instance hold a pointer-like member to an external sf::String, so that nothing has to be applied when that string changes? Basically the class Text must know that the string has changed somehow, so as to display the updated string.

11

General discussions / Re: SFML 3 - What is your vision?

« on: April 24, 2014, 02:21:17 pm »

C++11 is by now almost entirely supported by major compilers. Also SFML 3 is still far away, which means there is more time for the last C++11 features to be supported. With this in mind, I think there is no doubt that SFML 3 should be using C++11 in its implementation as well as in its public API, and therefore make it not optional.
C++1y should wait though, as the norm is not definitive yet.

12

General discussions / Re: The new SFML team

« on: April 22, 2014, 01:34:25 am »

Nice birthday present.
Hope this major change is for the best in the long run. In any case, sharing one's power amongst a team is a remarkable event.

Hooray for SFML!!

13

General discussions / Re: Future release of SFML 2.2 (feedback needed)

« on: April 01, 2014, 01:23:51 pm »

I guess any bug or regression that does not lead to a change in the current API should be fixed, whether it is critical or minor. That goes for any release of any application, actually.

My 2 cents.

14

General discussions / Re: Debian/Ubuntu packages for SFML

« on: December 27, 2013, 12:19:30 am »

SFML 2.1 is now part of Debian Testing: http://packages.qa.debian.org/libs/libsfml/news/20131222T163915Z.html. The current status of the package can still be seen here: http://packages.qa.debian.org/libs/libsfml.html.
Of course Debian Stable will be updated to SFML 2.x only when the new version, Debian 8 aka Jessie, is released. This should happen around late 2014 or early 2015.

15

General discussions / Re: Better keyboard handling

« on: November 29, 2013, 09:59:53 pm »

To take two examples, the Qwerty layout and the Azerty layout do not share an identical, physical key distribution:

• See Qwerty: http://upload.wikimedia.org/wikipedia/commons/3/3a/Qwerty.svg
• See Azerty: http://upload.wikimedia.org/wikipedia/commons/c/ca/Azerty_fr.svg

As you can see, Azerty has:

• an additional key with "<" and ">" on the bottom-left corner (where Qwerty has a large Shift key),
• an additional key with "*" and "µ" on the right (where Qwerty has a large Enter key).

And Qwerty has an additional key with "\" and "|" on the top-right corner (where Azerty has a large Backspace key).

Wouldn't these differences, amongst others with other layouts, make things difficult?