Messages

1

SFML development / Re: Window state

« on: February 21, 2018, 05:14:38 pm »

Huh thats weird... It seems like the compiler can't find State in Window.cpp eventough WindowState.hpp is included in Window.hpp...

What compiler/operating system + versions are you using?

As a fix you could try including WindowState.hpp in Window.cpp and see if it compiles.

Also than you for giving this a try! 

2

SFML development / Re: Window state

« on: February 15, 2018, 05:47:43 pm »

No comments ? Nobody tested?

3

SFML development / Re: Window state

« on: February 11, 2018, 05:10:19 pm »

Hello there!
I just pushed my windows implementation for the window state API. You can find it here.
From my tests it works quiet nice, but more testing and feedback would be great.
I have also encountered a really weird bug, which prohibits you from switching to fullscreen a second time, after you've switched back to windowed mode. The comparison on this line always fails, even if my debugger tells me state is State::Windowed. It is super weird and I can't figure it out, maybe somebody else knows more.

Here is he test code I have been using. Feel free to test and comment!

(click to show/hide)

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

void printState(sf::Window& window)
{
    switch(window.getState())
    {
        case sf::State::Minimized:
            std::cout << "Minimized" << std::endl;
            break;
        case sf::State::Maximized:
            std::cout << "Maximized" << std::endl;
            break;
        case sf::State::Windowed:
            std::cout << "Windowed" << std::endl;
            break;
        case sf::State::Fullscreen:
            std::cout << "Fullscreen" << std::endl;
            break;
    }

}

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "Example", sf::Style::Default);

    bool isHidden = true;
    // run the program as long as the window is open
    while (window.isOpen())
    {
        // check all the windows events
        sf::Event event;
        while (window.pollEvent(event))
        {
            // "close requested" event: we close the window
            if (event.type == sf::Event::Closed)
                window.close();

            else if (event.type == sf::Event::KeyReleased) {
                // close if escape key was pressed
                if (event.key.code == sf::Keyboard::Escape) {
                    window.close();
                }
                else if (event.key.code == sf::Keyboard::M) {
                    window.setState(sf::State::Minimized);
                    sf::sleep(sf::seconds(3));
                    printState(window);
                    window.setState(sf::State::Maximized);
                }
                else if (event.key.code == sf::Keyboard::N) {
                    window.setState(sf::State::Maximized);
                }
                else if (event.key.code == sf::Keyboard::W) {
                    window.setState(sf::State::Windowed);
                }
                else if (event.key.code == sf::Keyboard::F) {
                    window.setState(sf::State::Fullscreen);
                }
                else if (event.key.code == sf::Keyboard::H) {
                    isHidden = !isHidden;
                    window.setVisible(isHidden);
                }
                else if (event.key.code == sf::Keyboard::G) {
                    printState(window);
                }
            }
        }

        // clear the window to black
        window.clear();

        //window.draw();

        // display the windows content
        window.display();
    }
    return 0;
}
 

Also maybe some more people have an opinion on whether or not to have a state parameter in the constructor

4

SFML development / Re: Window state

« on: February 07, 2018, 07:44:58 pm »

I though we finally desided in that recent discussion, that we want to start moving forward with SFML again. And while keeping the API freeze in place use deprecation to implement new features. This would be such a case
I know it feels a little clunky to have 2 calls now to open a window in fullscreen instead of one. Thats why I originally proposed to have state as a parameter in the window constructor. Laurent argued against it, since the same can be accived with a initially hidden window that is then put into fullscreen state. The new API is also more powerful in the ragard, that you can make all the changes to a window, before showing it.


Sooo I uploaded a first implementation for MacOS. Not everything works, but it gives you an idea and can serve as a foundation for further discussions. You can find it in my feature/window_state branch.

So here are some implementation questions for MacOS. I haven't programmed a lot of Objective C (none actually ) so some questions might be easy to answer.

* when do I use self and when nil as parameters on NSWindow functions (both seem to work)?
* For the Hidden Style, calling orderOut directly after window creation doesn't hide the window. Actually on OSX right now it doesn't work if you do this:

sf::RenderWindow window(sf::VideoMode(800, 600), "Example");
window.setVisible(false);

From my test setVisible only starts working after the second run trough pollEvents.
I did look into what other librarys or people on the web did (there isn't much), but they all seem to be using orderOut.
* The fullscreen state is not implemented yet, as I'm not quiet sure of how to go best about it. It would probably need some refactoring of the init methods. I would need some input from mantognini on this.
* Also I get warning for the WindowImplDelegateProtocol methods not being implemented for SFViewController. From what I see the implementaion has to be dupicated, right? I am not sure what the design is here.


So yeah I mostly need mantognini input on the Mac version
I will try to start a windows implementation tonight.


edit: fixed one bug! also list and [ s ] together seems to be broken

5

Graphics / Re: Enable anisotropic filtering

« on: February 05, 2018, 11:48:10 pm »

Hmm I don't think it should be enabled by default when filtering is enabled, as it may come with quiet a performance impact (wikipedia).

6

Graphics / Re: Enable anisotropic filtering

« on: February 05, 2018, 09:49:36 pm »

Well I guess it could be done. The question is how to find a good API for implementing it. It would of course be nice to set a kind of level for the texture filtering. Something like

enum FilterLevel
{
    Nearest,
    BiLinear,
    Anisotropic
}

But it will be difficult to fit it to the current Texture::setSmooth API.

7

SFML development / Re: Window state

« on: February 02, 2018, 04:14:46 pm »

I thought it sounded weird, thats why I was confused
Well ok, I guess this would be possible too. I don't really see anything that speaks against it. It is nice to have the constructor with few arguments, but I wouldn't consider the wrong order a real problem. One thing that will be unexpected for users is that the default way to create a fullscreen window will look like this:

window.create(videoMode, title, style | sf::Style::Hidden, settings);
window.setState(sf::State::Fullscreen);
window.setVisible(true);

Which might be confusing as you didn't really have to deal with those things before.
Also thinking about it I would consider the visibility more of a state than a style, but then the design you proposed wouldn't work.
Another question I have is what happens if the user only passes sf::Style::Hidden to a window and then calls setVisible(true)? Should a default window (Titlebar | Resize | Close) or a window without any decorations (None) be shown?

8

SFML development / Re: Window state

« on: February 02, 2018, 11:24:13 am »

Thanks for the feedback.
But now you got me confused. I understood it like exploiter explained it.
So to my understanding you propose the following: As discribed above by me, but don't add a new style parameter to create, but instead always create a window in the hidden state. So a reagular call would look something like this:

window.create(videoMode, title, style, settings);
// or
window.create(videoMode, title);
// window is NOT visible at this point

// call some setters

window.setState(sf::State::Windowed); // or maximized or whatever

9

SFML development / Re: Window state

« on: February 02, 2018, 01:21:49 am »

Cool, thank!
Well I think with the proposed API you could achive similar results. When you pass the style to the create method the style is applied to the window directly on creation. On windows this is possible by passing the dwStyle flag to CreateWindow. The style can be any of these. So in order to get a hidden window you could create a minimized window. Of course you could also start with a maximized right away.
On MacOS NSWindow does not seem to have a way to apply a style on init. We will have to see if there is a flickering when applyed immediately afterwards.

10

SFML development / Window state

« on: February 01, 2018, 11:35:24 pm »

Hello everybody,
I was looking into a ticket that I have already been working on in the past. It is on maximing a window from code. Reading over the discussion again it seems to end with an already pretty good concept for an API. I though about it some more and I want to propose a design here. I'd like to hear your thoughts and if we can agree on it or develop it further I would like to start an implementation soon. Oh and a thing you guys are gonna like: we don't have to change the existing API, except for one deprecation

So I would suggest this:

enum State
{
    Windowed,
    Minimized,
    Maximized,
    Fullscreen
};


sf::Window::State state = sf::Window::State::Minimized;
window.create(videoMode, title, style, settings, state);
state = window.getState();
window.setState(state);

So as you can see we have a seperation between state and style. Style is now only for the appearance/decoration of a window. The state of the window can now be described seperatly. An enum somewhere contains the possible window states. States are exclusive, so a window can only ever have one state. The create method will be extended by another parameter for the style, which can default to Windowed. The platform implementation of create will then open the window in the given state. There is also a getter and a setter in sf::Window. The setter will simply apply the state to the window. The getter will return the windows current state. Those are all the additions to the API. The Fullscreen window style would have to be deprecated in order to make a clear distinction between style and state.

This API would have two welcome side effects. You could finally switch to fullscreen mode and back (at least I have found it very annoying in the past that you always have to recreate the window for that, especially since things like the mouse visibility are not saved). Also it would allow creating a hidden/invisible window on creation by passing the minimized state to the create function.

So I would like to hear your thoughts on this

11

Audio / Re: open AL unexpected message

« on: February 01, 2018, 12:04:25 am »

It would be more helpful if you could discribe what kind of problem you encounter specifically.
Also have you tried the current master? OpenAL has been updated between 2.4.2 and now.

12

SFML development / Re: iOS development progress

« on: January 30, 2018, 10:06:09 pm »

Probably related to this PR: https://github.com/SFML/SFML/pull/1263


Something else I saw recently is that according to this commit message the iOS implementation of the Clipboard API was never tested at the time. So now that we have some developers using iOS it would be great if one of you could test it

13

Graphics / Re: Enable anisotropic filtering

« on: January 30, 2018, 01:55:01 pm »

There seems to be some confusion what you are trying to request. If you already have some test code, please post it so everybody can check it out. Maybe some screenshots would help too.

14

General discussions / Re: Unfreezing the API

« on: January 27, 2018, 03:41:37 pm »

Puh!
What a wall of text I will try to respond to it all while staying short.
First of all I would like to thank everybody who is engaging in this discussion. I think it is very good we are having it!
Also another point I would like to get out of the way, because I think it was missunderstood, is that I'm definitly not interested in having big companies run SFML. I am all for hobbyiest and independent developers. The point I was trying to make was about assumptions that have turned out false and that I think adaption to the changes is needed.
Reading over all this I think I have to state again, that I do agree with most of the things that were brought up. Obviously unfinished things should not simply be merged. In order to find good solutions to a problem or a good design for an API discussions are absolutly necessary. I do enjoy a stable API and I don't want a new core part in every new minor version, but maybe we can find a way to be less pedantic about it and allow for smaller changes.
As eXpl0it3r explained the community participation comes in varying different qualitys which doesn't make work easier and obviously can not just fill in for the work of a dedicated team. You listed may reasons why development on commuity contributions stops. Thats why I say we have to make it as easy as possible for the people who are actually willing to put in work. If it's a enjoyable proccess to them, they are more likely to help again.
Maybe the plea for opening up the API was a bit of a compulsive reaction and I was trying to take a shortcut that eXpl0it3r mentioned, because it has fallen on my feet so many times. In the end what I really want to acchive is to help make SFML development quicker and make the process more enjoyable for those dedicated. Maybe there are other things to target instead, but I am sure SFML can benefit from changing come rules.

15

General discussions / Re: Unfreezing the API

« on: January 25, 2018, 09:49:32 pm »

Sorry my last post was a little rushed, because I had to leave.
My intention was not to pinpoint every feature and discuss why exactly it has failed. I wanted to show some examples where the mentioning of SFML 3, which implys not breaking the API now, led to the development dying down. It generates the vibe/feeling of lets not do things right now, but do them properly later. It discurages people from investing time.

Please don't get me wrong I am not trying to shit on anyone or blame somebody for something. I am worried about the future of SFML. It would be really sad to see it die down.
The situation from a couple years ago to now has changed. Thats why I say the rules made back then have to be reevaluated. My reasoing is since there is less contributions from the team now, we have to rely on more contributions from within the community. So we have to make it as easy as possible for people to contribute. The way the API freez is right now, its hurting SFML more than it does good for it. Maybe you can tell me some advantages that I've missed. Like I said before, I can understand were this is comming from and I don't want to just get rid of it. A stable API is a nice thing! I want to have a discussion about it. It would be fantastic if more people could join in.
I think SFML can benefit from changing/adapting some rules. Maybe we can come up with something that motivates more community members to contribute and helps to speed up the development again

I agree that getting the SFML 3 development started is also a big problem. But I'll leave that to the team Great to hear that you started to work on some stuff. I would love to contibute!