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 - Foaly

Pages: 1 [2] 3 4 ... 31
16
General discussions / Re: Unfreezing the API
« on: January 25, 2018, 06:37:24 pm »
Thanks!
Yes I know in theory the distinction between breaking change and change is made, but in reality it comes down to people thinking better leave it so I don't have to deal with changing the API. Or you have to spend a unnecessary amount of time to find an implementation that fits the old API.

About the examples, I don't have a proper list of all the changes that didn't happen/were delayed, but here are some things of the top of my head:

* A proper API for setting window states (differentiating between style and state)
* Multi monitor management
* Output streams
* Angles class
* Using any modern C++
* ...

I guess the last one is my biggest pain point. There were sooo many times a better solution using a modern version of C++ could have been used.

17
General discussions / Unfreezing the API
« on: January 25, 2018, 02:48:37 pm »
Hello everybody!

I would like to talk about the ban on API changes. For years there has been the rule in place to not introduce changes that alter the public API in any way except in major version releases.

I understand the desire to have a stable, reliable API. Afterall one of SFMLs strong points is its clean and simple API. To my understanding the incentive when introducing this restriction was to make SFML more attractive for bigger projects and companies. The reasoning was that for game studios or companies it is uneconomic to have to refactor their code base every couple month when a new version with a changed API of SFML is released.

In my opinion the assumptions have failed the test of time and have actually done more damage than good. Here is why I think that. From what I can tell (and please correct me if I am wrong) not many companies/studios use SFML for producing games since the limitation was introduced. The biggest chunck of users are still hobby developers, people learning graphics development/OpenGL and small projects. There are occasionally some polished and finished games on some game distribution platform or app store. I think its absolutly fine to confront people learning, studying or simply enjoying graphics programming with new features and potentially a couple minutes/hours of work when updating to a new version. I would actually argue that those users enjoy updates/changes.
Most importantly though the assumptions there will be a new major version "soon" turned out to be false. Back when this was introduced SFML 2.0 had just been released, the new development team had just been founded, development was going strong and there was a minor release about every half year. SFML 2 had just changed more or less the entire API so it made sense to say the next API change will happen in SFML 3. By that time and judging by the development activity at the time SFML 3 was thought to be release within a couple years. We are here a couple years later now and SFML 3 is still a couple years away. Development has slowed down significantly and there is a minor release about once a year. So any advances will just continued to be halted for years?

More that any of that I think that the attitude displayed to outside developers with this is extremly toxic to progress. Be it one time contributors or people enjoying sending patches every now and then. Reading something like: "yeah thanks thats a nice idea. we could implemented it right now, but we won't. why don't you come back in like 2-3 years, then we will think about it again". It is extremly discouraging and I have seen this many times. I think we can all agree that given the pace of SFMLs current development we should make it as welcoming and easy as possible for contributors to help.

So in the good old fashion of proving a necessity could somebody from the team please provide a concrete use case for an API that is stable and without change for years and years on end.

Sorry if this comes across harsh. I am not trying to hate on anybody. Its just that its incomprehensible and mind-boggling to me to see the already slow development of SFML being crippled even further for no advantage. But this is a discussion please let me know your opinion.

18
System / Re: sf::Vector comparison operator (< and >)
« on: April 11, 2016, 02:56:01 pm »
I see that makes sense. I didn't think of that. Thanks for the answer!
I use this code to clamp to the window size now:
mousePosition.x = std::min(windowSize.x, std::max(0.f, mousePosition.x));
mousePosition.y = std::min(windowSize.y, std::max(0.f, mousePosition.y));

I still don't quiet understand, why the compiler didn't recognize the operator overload. (removing the space didn't change anything.

19
System / sf::Vector comparison operator (< and >)
« on: April 11, 2016, 01:33:50 pm »
Hi,
I want to create a element at the mouse position. I order to keep it within the window I want to clamp the mouse position to the windows dimensions. Maybe I am just being stupid here, but I can't get it to work...
Here is the code I am using:
#include <SFML/Graphics.hpp>
#include <iostream>
#include <algorithm>

template <typename T>
bool operator <(const sf::Vector2<T>& left, const sf::Vector2<T>& right)
{
    return (left.x < right.x) && (left.y < right.y);
}


template <typename T>
bool operator >(const sf::Vector2<T>& left, const sf::Vector2<T>& right)
{
    return (left.x > right.x) && (left.y > right.y);
}

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

    // 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::MouseButtonReleased && event.mouseButton.button == sf::Mouse::Left)
            {
                auto mousePosition = window.mapPixelToCoords(sf::Mouse::getPosition(window));
                const auto windowSize = sf::Vector2f(window.getSize());

                // clamp to window size
                mousePosition = std::min(windowSize, std::max(sf::Vector2f(0.f, 0.f), mousePosition));

                std::cout << mousePosition.x << "x" << mousePosition.y << std::endl;
            }
        }

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

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

I am getting these compilation errors for the std::max and std::min templates: no match for 'operator<' (operand types are 'const sf::Vector2<float>' and 'const sf::Vector2<float>')
and operator> respectively. I don't really know whats wrong since I do define these operators above. Maybe somebody can tell me whats wrong.

This also got me wondering: Is there a reason why these operators are not defined by SFML?

Thanks in advance,
Foaly

20
Audio / Re: Use of locks in sf::SoundStream::onGetData
« on: February 02, 2016, 03:40:13 pm »
Like you said it is generally a very bad idea to allocate memory or do any kind of blocking operation in a "realtime" situation. onGetData would be one of them. Where exactly in the tutorial do you see memory being allocated or locks being used?

21
Feature requests / Re: Force Feedback Support...
« on: January 23, 2016, 06:34:24 pm »
I remember researching this a while back, because I was also interested in this feature.

On Linux is seems fairly straight forward. There are some ioclt and file wiriting calls and thats pretty much it. There is some information in the kernel doc.

On windows the whole thing is a little more complicated in our case. If I recall correctly SFML is using the windows 2000 (by now deprecated) multimedia joystick API. Force feedback is not supported there. For that you have to use the DirectX DirectInput system. This means we would have to rewrite the sf::Joystick windows implementation to use DirectX. But maybe that has to be done at some point anyway.  My research kinda stopped there, because I don't have much knowledge of DirectX. Also I don't know if using DirectInput means that you have to provide DirectX Redistributables with every SFML application (with would suck) or if windows already provides it automatically.

I have no idea about MacOS, but I guess it may be them same as on Linux.

Maybe this information is usefull for somebody. For the interested this is how SDL does it.

22
General / Re: SFML 2 and Qt 5
« on: January 17, 2016, 01:14:43 pm »
Oh man that sucks...  :(
So just a quick summery to make sure I understood it correctly. There is no way to get Qt and SFML working together out of the box on Linux, because of the XCB Xlib event handeling incompatiblity. Seperating rendering and event handling won't work either, because rendering relies on event handeling (like you said buffer swapping in .display()) The only way around would be to hack the libraries to share their OpenGL context, right?

One follow up question: You were talking about linux here, but I experience the problem I described on windows (win 8.1 mingw gcc 4.8.1). Is that related somehow?

23
General / SFML 2 and Qt 5
« on: January 15, 2016, 01:41:47 pm »
Hi everybody!

As the title suggest I am trying to set up SFML and Qt to work together. I know this has been done before and I am probably just being stupid somewhere, but I ran into some issues. I couldn't find a complete example/template that uses recent versions of SFML or Qt. Thats why I thought I just ask here.

So here is my code. It is of course based on Elias Dalers awesome project and the existing wiki page. I pushed my code into a repo to make it easier to download.

(click to show/hide)

As you can see in the screenshot most of the stuff is already working. The weird part I am having trouble with is that some events do not reach in the SFML window event loop. For example I do receive MouseButtonReleased and Resized events, but I can't get any MouseWheelScrolled or KeyReleased events. Does anybody have a clue why thats happening?
Also I can't connect the button to a function, but I think thats an unrelated problem. Still if somebody knows why that would be a great help.

Here is the error output when the program is run:
(click to show/hide)

I hope that somebody how has more experience with Qt and SFML working together can help me figure this out.
Maybe we can put it on the wiki once its working. I am sure it can be useful to other people in the future as well.

Thanks in advance,
Foaly

24
Audio / Re: Real Time audio processing (Input From Sound Card)
« on: January 08, 2016, 10:58:04 am »
Yes that is correct sf::SoundBufferRecorder is not what you are looking for. If you want to do near real-time processing you need to derive from sf::SoundRecorder. Then you can implement the onProcessSamples() method, which will provide you with the samples at a specified rate. Take a look at the doc or the implementation of sf::SoundBufferRecorder. Also the VoIP example might show you a way how to do it.

25
Audio / Re: Continuous audio stream
« on: December 10, 2015, 06:17:03 pm »
Have you taken a look at the VoIP example? It shows a use case of sf::SoundStream.
https://github.com/SFML/SFML/tree/master/examples/voip

26
General discussions / Re: Continuous Integration
« on: December 01, 2015, 09:01:42 pm »
Ah I didn't think of Cmake...
Well it was just an idea. Maybe a manual option could be investigated. Even if not, this is still very cool!

27
General discussions / Re: Continuous Integration
« on: November 30, 2015, 11:01:32 pm »
I see. But how big is the risk? From my understanding the code is only compiled on the machines and not run (exept for maybe unit test in the future). Also the code for generating the build is always open to see.

I'm just thinking it would be nice for developers outside the SFML core team to also benefit from that. I for example have access to a Mac at work which I could use to test. But I don't have a build setup there.

If it's possible the build for pull requests could also be triggered manually once someone has done a code review.

28
General discussions / Re: Continuous Integration
« on: November 30, 2015, 09:54:33 pm »
This is really cool. I think it will definitly be helpful for testing. If you want to have a quick way of testing new stuff without having to build it yourself (maybe on a platform where you don't have a build setup...). Also its a nice way to ensure the code compiles on all platforms.

One thing that would be a nice addition is to also extend the builds to pull requests. That way developers that are not in the core team can befit from this as well.

Anyway this is really nice! :)

29
General discussions / Re: Logic error handling in SFML
« on: November 29, 2015, 10:59:05 pm »
Since I was responsible for some of these pull requests, I guess I should answer something to this.
I come from a background where it is desired to keep the programs running for as long as possible, despite maybe some wrong input. I now come to realize that from a library standpoint this might not be what you want.
I think using assertions to prevent logic errors by showing library users, that they are doing something wrong is a great idea.
If you are looking for a way to interrupt the debugger immediatly I suggest a custom assert implementation. You could emit a interrupt 3 which triggers a breakpoint. A way of doing this is shown here. A custom assert also brings the possiblity of printing a message explaining how to fix the problem. This can be benifitial in cases where the fix is not trivial on first sight. (For example the current audio capture threading issue, where you have to call stop() in the destructor of the deriving class) Some thing like this.
Overall I think it is a good idea to use more asserts to improve the usability of SFML.

30
Feature requests / Re: SoundRecorder improvments
« on: November 29, 2015, 04:25:17 pm »
Ok I went with get/setChannelCount and made a seperate pull request. This way brings the possibility that it can be extended to more channels in the future without changing the API and its also consistent with the other sound related classes.
When set I limited the channelCount to two and print a warning if a higher value way entered. Fell free to take a look at the code and send me some feedback!

I also made a pull request for the threading issue.

Pages: 1 [2] 3 4 ... 31