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

Author Topic: Concerned and Eager  (Read 4224 times)

0 Members and 1 Guest are viewing this topic.

unlight

  • Newbie
  • *
  • Posts: 33
    • View Profile
    • Email
Concerned and Eager
« on: May 26, 2020, 04:52:27 pm »
Hi guys,

I would like to share some thoughts that have been plaguing me a bit recently.

I am a huge fan of SFML and I feel quite heavily invested in the project, but I am a bit concerned about how the library will continue to keep up with changes in the industry. I have been lurking around here for long enough to have seen discussions on all of the things that concern me. Two of my main concerns are:

Rendering Backend - OpenGL deprecation is going to be an issue at some stage, support for multiple rendering backends has been discussed/prototyped which is great!

C++ Standard Integration - There are classes in SFML that have been made obsolete by features added in newer C++ standards (mostly thread related). There are also some concepts, such as move semantics, that really should be implemented.

While neither of these are actually a real issue at this very moment, I am concerned about how long it will take to adapt the library when they do become immediate issues. I know that the library is maintained by the devs in their spare time, and the dedication you all have is incredible. However, I know SFML 3.0 is far beyond the horizon and I am not sure that the official plans even encompass the pending rendering backend issue?

I guess that what I am trying to articulate is that I am concerned about SFML being left behind by the industry. These concerns may be completely unreasonable, but I know some others share the same (see Elias blog post about moving away from SFML in favour of SDL for similar concerns), but I have them none-the-less.

Instead of worrying about this, the better thing to do would be to help contribute. I have already said that I was going to work on implementing move semantics for the library, but I am having second thoughts because I don’t think move semantics are on your critical path (making it a low-priority pull-request).

With that said, what can I do to help SFML with something more immediate that would help push towards 2.6 or 3.0? I am keen af.

Any thoughts or suggestions?

Ruckamongus

  • Jr. Member
  • **
  • Posts: 70
    • View Profile
Re: Concerned and Eager
« Reply #1 on: May 26, 2020, 05:18:51 pm »
Unfortunately, I agree with this sentiment. I love SFML for what it is, and it's still great for quick prototyping, but the lack of development is off-putting. Yes, I realize it's community based without a dedicated developer, but there have been features that get discussed for months or even years with back and forth banter that inevitably resolves to either "not in the scope of SFML" or "it'll break API, maybe in the next version." I agree that good discussion and planning is important, but what's the point of nothing comes from it? I'm discouraged to even try to expand and submit a PR because I feel the time will be wasted while it sits stagnant on GitHub to be discussed to death.

Small bug fixes and infrequent quality of life changes are always welcome, but the project as a whole feels dead. Maybe this is a bit abrasive, but the apprehension to move forward has left me disappointed over the last few years.

 ;)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
Re: Concerned and Eager
« Reply #2 on: May 27, 2020, 01:12:31 am »
The Roadmap for SFML 2.6 and SFML 3 has been relatively unchanged for quite a while, yet I see very little movement from the community, then again as mentioned in the linked thread, people seems to be really eager for a more modern C++ code base, as such people may just be waiting until SFML 3 finally kicks off.
We had cleaned up the SFML 2.6 project on GitHub quite a bit in the past and just today, I basically removed anything that would require additional work or discussion and updated the Roadmap.



As for the longer discussion...

I'm highly biased so my comments may not reflect reality ;D

There are multiple levels to all of this and it's hard for me to bring it to the point, but I give it a try.

In the SFML 1.x and early 2.x periods we had Laurent as the driving force behind SFML, pushing a lot of topics forward on his own and seeing them through from idea to final implementation.
Over the past years we tried to turn the project into a more community-driven mode, but the big success is still unaccounted for. Here are a few observations of mine:

SFML has a high quality standard

We try to get the code (and commits) as good as possible before merging them. This leads to Pull Requests not being accepted (but also not rejected) that don't meet that "quality". The advantage is that once a feature is merged, it has been tested, is stable and usually doesn't require regression fixes.

Personally, I don't think we should make compromises here, as it would only reduce the quality and push the required work further back.

SFML is cross platform

A lot of people underestimate the amount of work required to implement a "simple" feature. You have to pick an API design for SFML, then you need to make sure that it works for Windows, Linux and macOS and then you need to implement for all these platforms and after all that, there's still Android and iOS.

I could see some room for providing feature implementation for just one platform, but this has the danger of diverging the feature sets and making the library less "cross-platform".

Technical Discussions

It's tedious and requires time, but it's essential to have technical discussions. Very often people feel offended or walk away when they get confronted with questions.
It's not enough that you like a feature or that you already coded said feature. In order to keep the API simple and maintainable, we need to consider the broader use-cases for a feature. Once you know the 'why', the question moves to the 'how', which usually offer multiple designs that need to be weighed one against the other.

I'm the first to admit that we had a lot of discussions that ran a bit out of hand in the past, but let's try and leave the past in the past. I think it's essential to have discussions on topics, at the same time, if someone provides a complete implementation of a feature and provides some good arguments why this is a valid use-case, it's rare that it will be outright declined.

Active Discussions

binary1248 has created various pull requests with potential changes and made them public so everyone can take a look, provide feedback and scrutinize the design decisions taken. But the activity on these PRs are very low. If we want to move forward, we do need active conversations - those are often the more valuable contributions!

Nobody owes anything to SFML, but you also need to understand how it personally frustrates me, when there's a draft pull request with only two comments on it and on the other side, people pretend that SFML is dead and lacks some features. If you want a feature, you need to get active and help get the feature finished. ;)

Champions

In an ideal world the SFML Team would pick up existing pieces and completely new features and start pushing them forward until they reach the finish line. But being more community-driven this responsibility would now be with everyone. Unfortunately, we still get a lot of contributions that are well intended, but get stuck after the first or second review or discussion point. I understand that the excitement goes away after the first few hours or days, but it's crucial that features are not just thrown over the fence and left for others to finalize, but that the author (or some other contributor) champions the topic. That means: rebase whenever there are merge conflicts, implement review comments, ping reviewers, keep the discussion on open questions active, etc.

SFML is relying on the community, as such the will to do something is not enough. I also want to spend more of my free time on SFML, but often end up doing other things. Pick a topic, start a discussion and champion it from start to finish, that's how SFML is moved forward.

tl;dr
  • Join and/or start discussions on topics that you're interested in
  • Champion already existing topics and push those over the finish line
  • Right now: SFML only progresses if the community works on it, so let's get to work! :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

unlight

  • Newbie
  • *
  • Posts: 33
    • View Profile
    • Email
Re: Concerned and Eager
« Reply #3 on: May 27, 2020, 02:15:51 am »
Quote
SFML has a high quality standard

We try to get the code (and commits) as good as possible before merging them. This leads to Pull Requests not being accepted (but also not rejected) that don't meet that "quality". The advantage is that once a feature is merged, it has been tested, is stable and usually doesn't require regression fixes.

Personally, I don't think we should make compromises here, as it would only reduce the quality and push the required work further back.

I agree that compromises should not be made here, but I can see why it could slow down progress when it feels more like work than play to contribute.

Quote
SFML is cross platform

A lot of people underestimate the amount of work required to implement a "simple" feature. You have to pick an API design for SFML, then you need to make sure that it works for Windows, Linux and macOS and then you need to implement for all these platforms and after all that, there's still Android and iOS.

I could see some room for providing feature implementation for just one platform, but this has the danger of diverging the feature sets and making the library less "cross-platform".

I would lean more towards providing implementations for platforms as they become available with exceptions being thrown in unsupported OS. You will get the good chemicals more often working on 5 smaller issues of  "implement and test X on Y OS".

Quote
If you want a feature, you need to get active and help get the feature finished.  ;)

I find this refreshingly motivating  :)

Thanks for the detailed response eXpl0it3r. I shall find feature to start pushing.