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

Author Topic: Rethinking the definition of "Simple"  (Read 11938 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Rethinking the definition of "Simple"
« on: April 19, 2014, 06:45:06 pm »
Given my post count, it should be quite obvious that I'm an SFML enthusiast and as such, I've been following many discussions here on the forum but also on IRC. What I've noticed with many discussions regarding API adjustments or feature request, is the argument of keeping things "Simple" as the library's name says: "Simple and Fast Multimedia Library". This is in general good, because it will prevent unnessecary API blow-ups and a like. Unfortunately I've also seen many make use of that argument, but interpreting the word "simple" differently and the longer the more it seems that the general definition is something along the lines of:

"Someone with nearly no C++ experience should be able to use it."

Sure it never gets spelled out like that, but if a discussion only arises around how to make the magic happen by only calling a function and not bother with anything else, it's in my opinion the wrong definition of "simple".

This all kind of leads to the question: Who's the target audience of SFML?
Should SFML be a library with the simplicity for the ones that have learned some C++ in a week and then maybe manage to create a pong game OR should SFML be a library that allows more advanced C++ programmers to create fully featured 2D games, while providing an power full, yet simple and well documented API?

If we're amiing just for the first group ("newbies"), then I strongly believe SFML is not worth anyone's time, because if it's just easy to start with, even the newbies will once advance and notice that SFML doesn't have to offer enough complexity for bigger projects. SFML would then only be a gateway library to game programming.

So what's my point here? When discussing API changes or feature requests, we shouldn't ask ourselves whether newbies can use it easily, but instead ask whether the change would simplify the developer's life, whether it would allow the developer to focus more on the game itself. The focus of newbie-friendly features should shift to "scaleable" features, meaning an API that is more flexible, something that doesn't just work for the simple/newbie use-case but also for complex games and advanced C++ programmers.

Let's forget about "too complicated" and focus on "how do we make it simple"! :)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Rethinking the definition of "Simple"
« Reply #1 on: April 19, 2014, 07:38:51 pm »
I understand and I totally agree. That's why we are adding scancodes for improved keyboard handling, full customization of blending modes, more types of shader parameters, etc.

So what do you have in mind exactly?
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Rethinking the definition of "Simple"
« Reply #2 on: April 19, 2014, 08:38:10 pm »
That's why we are adding scancodes for improved keyboard handling, full customization of blending modes, more types of shader parameters, etc.
That's only completing features you already started.

What he is talking about is the fact that SFML tends to put a limit on what it expects a beginner to game programming to need for their first project. Anything beyond that is deemed (and I'm paraphrasing here) "not the target audience of SFML". One might think that adding more features than a beginner might initially need might intimidate them a bit, but hiding the true complexity of the matter at hand can only bring you so far. By primarily thinking of beginners you are saying that in order to keep using SFML, they either have to not make any progress at all in terms of development practices, or that once they have gotten the hang of things and completed their first few projects, they can go and use another library that allows them to do more. If that is really what the philosophy of things is (and I really hope it is not) then it is quite sad that a library with so much potential is artificially limiting itself when it does not have to.

Time and again, I have tried digging through old posts of feature requests, here and on the tracker dealing with adding more "enthusiast" features only to get forgotten about, because there wasn't much interest on the side of the community and the initial person who made the suggestion probably left SFML for greener pastures or worked around their problem.

The reason why the feature set needs to be so limited was never really mentioned anywhere. The step from SFML 1.6 to SFML 2 was mainly about the drawable update and API aesthetics, but in terms of actually providing users more to work with to build more complex projects, I didn't really see many additions. SFML 2 has been around for a while already, and there isn't any official or unofficial roadmap for SFML 3.

What eXpl0it3r is suggesting is that SFML consider expanding its target audience in new directions, exposing platform features in a completely optional way. You already showed us that you can do that with sf::Shader by allowing the user to check for support before using it. Why can't more features be implemented like that? If a developer knows they don't want to target machines more than 8 years old then let them decide for themselves.

That is what he means with the definition of "simple". You have to ask yourself, who is it supposed to be simple for? Surely the same thing might not be as simple for one person as it might another... I could probably write a 90% complete shader without having to look anything up on the OpenGL wiki whereas others might find using the sf::Shader class daunting. For example, if you have a class called sf::TransformFeedbackBufferObject does that necessarily mean it will make life for beginners less "simple"? Not really. And people who want to use that feature with its clean interface will rejoice that SFML makes their lives simple as well.

I think a better definition of the word "simple" would be "easy to use" as opposed to the (in my opinion) current definition of "easy for beginners to understand". If you are a beginner, fine, there is nothing wrong with that, you can leave the more complex stuff for later, but don't limit what others who were here before you can do. Not everybody decided to pick up game programming at the same time, and those who are at it for longer will naturally have other needs than those who just started yesterday.

Now, you might bring up the "do it in X yourself" argument, X being OpenGL, win32, etc. If that is the case, why even bother providing something like sf::Shader in the first place? Obviously it requires knowledge in GLSL and so it can be expected that if the person reads about GLSL they will also get exposed to "normal" OpenGL programming in some form. One could argue that once you need shaders you might as well drop the SFML drawable API in favour of just doing everything yourself in raw OpenGL. Once you need some specific cross-platform feature that is not in SFML but is widely used everywhere, you should roll your own implementation. Is this the right way to go? If you ask me no. SFML can make these otherwise complex and time consuming things "simple" to do for advanced users who need them. And beginners who are looking for a library to stick with for a longer period of time are not shaken by the fact that once they do learn a bit, they lose the advantage that SFML provided them for the first 200 hours of development.

On the pages of many libraries, you often see lists of features that they support. When beginners look for a library, they will probably read through the list of features and decide if it is good for their needs or not. They might not understand or need all of the features, but that is natural. They might not know how to use a feature yet but maybe it might be something they want to try later on when they have a better understanding of the basics. Promoting a library's primary "feature" as its being easy to learn isn't attractive enough for me at least (and I suspect many beginners who do in fact plan ahead of time). The ones who probably land here the most are those that type "game programming simple" or something like that into Google and expect to be hand-held from start to finish. The ones who know how to compare libraries with each other might even start with something more complex such as Irrlicht or OGRE although they have no prior knowledge. I was one of those people a long time ago, and I eventually ended up using SFML because its API was much much cleaner than all the rest, and I saw potential in the idea that the complex things I had seen in those other libraries could be made simple to do. SFML already succeeds in doing many things in a cleaner, more simple way than other libraries. Window management, input management, audio are some of those things, but what about the rest? There are many things that those libraries do that SFML never tried or even considered doing. Is it because no simple API could be designed for those features? I don't know, but I haven't found any serious long-lasting discussions about any such features.

If a beginner is overwhelmed and just gives up when their auto-complete shows them a list with 1000 entries then I say they should not be your target audience. Trial and error is not the most effective way to learn anyway. Think of SFML like any RPG. In RPGs your character levels up and becomes more powerful over time. They acquire more abilities/spells to choose from every level and more slots to equip them in. Is it a good idea to give a level 1 character 1000 spells to choose from? Probably not, since they haven't gotten the hang of many mechanics. Is it a good idea to limit the level 200 character to the same 10 spells that they had access to at the start of the game? We all know how well that game will do ;). SFML currently puts a very low level cap on the character and basically says: "You'll learn how an RPG works here. If you want to play a real RPG go play another game." I don't think veteran RPG players will enjoy this game for a long time, let alone even consider playing it ;).

It's not about the amount of things you present, it's about how you present them to your audience.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Grimshaw

  • Hero Member
  • *****
  • Posts: 631
  • Nephilim SDK
    • View Profile
Re: Rethinking the definition of "Simple"
« Reply #3 on: April 19, 2014, 08:40:52 pm »
I am not sure what eXpl0it3r is aiming for, but I would suggest that another module should be created in SFML.

Instead of destroying the current modules completely, I believe we should keep them in the same path (fixing little things, improving here and there.). However, as everyone can see, SFML doesn't give you a lot for making games, we rarely see someone come to SFML Projects with an actually polished project because it takes lots of work on top of SFML to make one.

A new module could solve this by starting to introduce additional things, usable at the beginner level. On the top of my mind, I can think of therocode, binary1234, lolz123, Nexus and other people's awesome code to put together a nice set of additional features. The main motto for my approach is that beginners have been starting out with SFML for years and always posting the same vanilla projects with a simple View and a movable character etc. Why can't those beginners still post vanilla games, but with quality taken up a notch?

The additional modules didn't need to be a part of the core SFML library, but also collaborative extensions supported officially. I can think of many features that could be really useful, could be exposed through a simple API and make all the sense for all kinds of multimedia programs. But let's not forget SFML is probably used for games 99% of the times..

Here are some features that could be added:

- A entity system (component based)
- A premade renderer for that entity system
- A nice state manager approach
- Promote one of the great UI extensions as official or build upon one of them a new Ui system
- Model loading and a basic scene format
- Particle system behaviors

I can relate these to libraries like Ogre for example. A scene format for example, it could be forcing the users down a specific road to some extent, but it would also give a lot of new possibilities. If there was a SFML spec for a format along with a parser, it would be enough that someone builds a graphical editor (and it would happen for sure) and everyone could benefit of it. It would be a nice way for beginners to have more complex and interesting scenes from the start.

I defend this kind of extension approach a thousand times more than the little adaptations to the graphical API, like the shader and blend modes change upcoming next. This is because most people will still write custom opengl instead of using the SFML graphics library once they get serious about their projects. Everyone would benefit from simply having more raw power from SFML.

It's just my opinion :)

Grimshaw

  • Hero Member
  • *****
  • Posts: 631
  • Nephilim SDK
    • View Profile
Re: Rethinking the definition of "Simple"
« Reply #4 on: April 19, 2014, 08:55:10 pm »
I'd just like to comment on binary's well written post; I agree with his point of view, SFML should slowly grow into something that can actually make multimedia apps, because the way I see it, the graphics module is that fantastic and clean API that lets you do a few things, once you want something beyond those basic things, you end up rewriting it from the start because while the module is well written, it is unnecessarily obfuscated with inner details.

The prime examples I remember are the limited shader, texture and render texture support. You want to do a deferred renderer? Cool, write your own render to texture system because SFML's is too closed to work with. You did? Now write a new texture support or mod SFML because you can't access the texture ID. Want to use fancy shaders? Here you have an awesome(imo) API for it, but sorry, you can't use the program ID or have more control over the texture binding process or what shaders to use etc.

SFML really needs to grow to meet the requirements of modern game development(specifically how OpenGL has been evolving), while keeping a simple API just the same, but that doesn't take our freedom to extend it if needed. I know Laurent meant well when he designed the latest graphics module, but it simply isn't the responsibility of the low level RenderWindow to manage batching and that kind of thing, there should be external classes specifically for it, optional classes. Another place that needs touching is the view part. View is a fantastic tool, but its relation to the RenderWindow class is bad in my opinion. RenderWindow should be agnostic to whatever camera is active, 2D or 3D, custom or not.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Rethinking the definition of "Simple"
« Reply #5 on: April 19, 2014, 09:18:30 pm »
binary1248, you probably have mainly the features you implemented in your 3D extension in mind? I personally think SFML could certainly provide more features in certain areas (especially with respect to modern graphics handling), but we should also keep in mind that it's a multimedia library. Its main advantage for the user is, in my opinion, the abstraction from low-level functionality: different operating system APIs for input, windowing, networking; OpenGL; various image, audio and font formats, ...

What I mean by this: we should not make the mistake of introducing too high-level functionality like particles, entity systems, GUI and other things that can as well be provided as an extension into core SFML. Having an extension has multiple advantages: there is more room for experiments, different people can come up with different approaches, development is less rigid. The focus of SFML should lie on the parts that cannot be provided by an extension, which includes improvement of the core libraries and the points mentioned in Grimshaw's last post.

When interfering with OpenGL, there's always a question to which extent the library can abstract things, and at which point you draw a border, where you have to say: "from now on use OpenGL". Ideally, the user wouldn't need to touch OpenGL even if using advanced functionality, so it would be good to steer in that direction. Even if a lot of internal details are private, they have one advantage (besides the obvious encapsulation): people who see a limitation in the API don't simply work around it, but come to discuss here, and contribute to an improved and extended API. Of course, that doesn't mean everything should be restricted, but I prefer knowing where the limitations are, so that also other users can benefit from possible improvements.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: Rethinking the definition of "Simple"
« Reply #6 on: April 19, 2014, 09:22:46 pm »
So what do you have in mind exactly?
What binary1248 and Grimshaw (in his second post) said! :)

Very short: Provide an simple API, but don't simplify the possibilities. One should be able to easily use SFML, while not getting (too much) limited, in regarding to what one could do without SFML.

Some examples can be found in Grimshaw's post.

I am not sure what eXpl0it3r is aiming for, but I would suggest that another module should be created in SFML.

I defend this kind of extension approach a thousand times more than the little adaptations to the graphical API, like the shader and blend modes change upcoming next. This is because most people will still write custom opengl instead of using the SFML graphics library once they get serious about their projects. Everyone would benefit from simply having more raw power from SFML.
My main focus was on changing the core of SFML, things that can't be fixed with some extensions. Or some features that are so essential or so close to the core that it would feel alien to have them separated from SFML (basically what Nexus said).
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Rethinking the definition of "Simple"
« Reply #7 on: April 19, 2014, 10:13:27 pm »
binary1248, you probably have mainly the features you implemented in your 3D extension in mind? I personally think SFML could certainly provide more features in certain areas (especially with respect to modern graphics handling), but we should also keep in mind that it's a multimedia library. Its main advantage for the user is, in my opinion, the abstraction from low-level functionality: different operating system APIs for input, windowing, networking; OpenGL; various image, audio and font formats, ...
I have a background in computer graphics and networking, so obviously I am more weighted in their direction. But agree with you on the fact that SFML is a multimedia library and what I said previously can very well be applied in other areas as well. I just didn't have any examples on hand.

What I mean by this: we should not make the mistake of introducing too high-level functionality like particles, entity systems, GUI and other things that can as well be provided as an extension into core SFML. Having an extension has multiple advantages: there is more room for experiments, different people can come up with different approaches, development is less rigid. The focus of SFML should lie on the parts that cannot be provided by an extension, which includes improvement of the core libraries and the points mentioned in Grimshaw's last post.
I know this. This is the reason why SFNUL and SFGUI are not supposed to be part of the core library. They require little to no changes to SFML to function. The former was originally written to interface with SFML, but as you might imagine, some features were impossible to implement if not done from scratch. In the case of SFGUI, a long time ago, when Tank was the only maintainer and I came to him with a few patches every now and then, his widget rendering was based entirely on the core SFML rendering API. This was enough... until then. As we added more features to the library that incurred more rendering, we noticed SFML was not designed to handle so much load, so the first optimization (hack) we implemented was creating a display list from whatever it was that SFML did to draw widgets. This fixed the performance issue... until SFML 2 came around. By that point display lists didn't cut it any more because of how SFML's new drawable API worked. I then began work on Project O, which was a retained mode OpenGL widget renderer and that has solved all performance issues and still does nowadays. If you look into the Renderer source code, you will still find hacks all over the place just to make it "compatible" with SFML without having to treat SFGUI as an arbitrary OpenGL-based library requiring pushGLStates() and popGLStates().

This is the problem with relying on the SFML drawable API for too long. You write your code using it. It does what you want for a while and at some point it won't be enough any more. What do you do then? Rewrite everything because you will likely need to resort to OpenGL and SFML's drawable API was not meant to interface with it that well. We need more extension points into the SFML API for functionality we might want to add externally.

Libraries such as SFGUI and SFNUL can be written with just a bit of knowledge of the SFML internals in mind. One just has to look at the external API and design so that the user won't have too much of a headache when trying to use them with SFML. Regarding scene graphs, entity management and other such things: they are completely orthogonal concepts. They have no real dependency on the specific way SFML does things and as such, they can exist as pure extensions. They are also a layer higher than SFML and as such sit on top of it, much like how SFML sits on top of OpenAL, OpenGL, sndfile etc. SFML should be about sitting on top of the really low-level API and just that. There is no point going higher or lower. In the former, it becomes too application specific to benefit enough people to warrant the feature itself and in the latter one has to ask themselves if they would be better off just using the underlying API directly. SFML is sitting in the sweet spot right now and it should stay that way. That does not mean by any chance that it doesn't have room to expand within the same layer of abstraction.

I'm sure you have heard of 3DEE by now. The reason why I chose to make it a fork of SFML as opposed to an extension was because it should be backward compatible with SFML. Why would you have to sacrifice all the existing drawable classes in favour of OpenGL when all you need is a different projection matrix? Without changes to the RenderTarget implementation itself, there was no way of achieving this, so obviously a pure extension wouldn't do the job. If there had been a way to specify what kind of vertex data the RenderTarget sends to the GPU depending on what is to be drawn, then maybe... maybe there would have been a way to make it a pure extension. But I tried, really hard, and I just saw too many roadblocks. SFML was designed to function with itself only. Extensions can only abstract SFML concepts to higher layers (e.g. scene graphs) but they can never add functionality because there are no extension points.

When interfering with OpenGL, there's always a question to which extent the library can abstract things, and at which point you draw a border, where you have to say: "from now on use OpenGL". Ideally, the user wouldn't need to touch OpenGL even if using advanced functionality, so it would be good to steer in that direction. Even if a lot of internal details are private, they have one advantage (besides the obvious encapsulation): people who see a limitation in the API don't simply work around it, but come to discuss here, and contribute to an improved and extended API. Of course, that doesn't mean everything should be restricted, but I prefer knowing where the limitations are, so that also other users can benefit from possible improvements.
I'm not asking for every feature that one could possibly think of. Most SFML users could probably live without sf::Shader if you think of it, and yet it exists. Probably because Laurent saw merit in the fact that you could implement interesting effects otherwise not doable without it (which is why it was named as it was in SFML 1.6). Why can't this apply to more concepts? Like I've probably mentioned more times than I can count, SFML still lacks buffer object support, although everybody with sufficient knowledge and even beginners who begin with modern OpenGL know how necessary they are nowadays. sf::Texture provides bind() for people to use with their OpenGL code (which we do in SFGUI as well), sf::Shader provides bind() for people to use with their OpenGL code. This is even mentioned directly in the documentation. Is it a bad idea to implement a class that is focused less on the drawable API and more towards OpenGL from the start?

I don't expect you to implement transform feedback support or any other 3.x/4.x feature for that matter. Most of the current GL API has been around since 1.5 and 2.0 in the form of extensions. Maybe one should not consider what the drawable API would need from GL but what certain GL features could do for the drawable API for once.

Creating a funtionality extension is the easy part. Making it work with SFML in a natural way is the hard one.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Rethinking the definition of "Simple"
« Reply #8 on: April 19, 2014, 11:38:52 pm »
This is really interesting and I basically agree with everything that is said. You can't imagine the number of ideas that I'd like to play with, if only I had free time to do so. In the past I had great ideas for SFML. But now, the sad truth is that I can hardly fix the most important bugs and add minor features. Even with help. Just have a look at the endlessly growing task list.

SFML is only surviving, and I have no idea what will happen in the future. Probably nothing exciting, given the amount of work that my job, my family and my house gives me every single day. When I see you talking about modern features, I feel like I'm light-years away from these things. This is so frustrating.

My dream would be that everyone in this topic join together and actively take over the development of SFML. Otherwise SFML will probably die slowly.
Laurent Gomila - SFML developer

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Rethinking the definition of "Simple"
« Reply #9 on: April 20, 2014, 12:03:29 am »
...
My dream would be that everyone in this topic join together and actively take over the development of SFML. Otherwise SFML will probably die slowly.
Arrgh. No. SFML is such a great library - it must not die.
This won't mean much in the grand scale of things, but for what it's worth as a SFML user I want to help out if I can (and have the time) and make sure SFML lives on. I'm sure we can do it :-)

Addition: Let's get SFML 2.2 out - if nothing else, then as a stop-gap measure. It'll get room/space/peace/whatever to work on SFML 3.0
« Last Edit: April 20, 2014, 12:22:42 am by Jesper Juhl »

therocode

  • Full Member
  • ***
  • Posts: 125
    • View Profile
    • Development blog
Re: Rethinking the definition of "Simple"
« Reply #10 on: April 20, 2014, 08:25:31 am »
I'll just also chip in to the discussion, saying that I too agree with the original post. IMO if the focus on a library like this is newbie friendliness and sacrifices are made for such, then as exploiter (not going to scroll back just to get caps and numbering correct :D) said, SFML will only be a "gateway" library, or a newbie haven.

This is tbh something I've already seen and experienced myself. In some cases in my own more "complex" use cases of SFML I've had to consider looking at other alternatives. I have also seen friends of mine and people on IRC do this. I find it a shame since I _do_ like the SFML library. It is the multimedia library with the nicest API out there. Which is why I believe that it has great potential.

SFML is only surviving, and I have no idea what will happen in the future. Probably nothing exciting, given the amount of work that my job, my family and my house gives me every single day. When I see you talking about modern features, I feel like I'm light-years away from these things. This is so frustrating.

My dream would be that everyone in this topic join together and actively take over the development of SFML. Otherwise SFML will probably die slowly.

Well, that dream does not sound too off in my opinion. :) I am pretty sure that many experienced people in this community would be glad to contribute and improve on the library. I myself would be one of them. But in all honesty (and no offence intended), for that to happen, the way SFML is managed would have to change I think. Because up until now SFML have been very "centrally" controlled by either you, or you + Nexus, and reading discussions on the forum, and participating in one (the audio bug one :D), there is not uncommonly a lot of resistance towards certain ideas. For example, I can't say that the audio bug discussion went smoothly. Nor did the discussion about getting the GLEW hack away. But both ended up being implemented anyway. Of course this is just my perspective on things, and maybe the other side of the discussion feels the same. :D But I do know that others I've talked to (Tank for example) feel the same frustration, and regardless of who is "right", it is not really a contribution-healthy way.

I personally would not feel great contributing if that's the process for many changes. But of course every change cannot be openly accepted straight away either, there has to be some form of control to stop useless requests, and focus on important things etc. Maybe it would be possible to have some kind of "SFML Committee" kind of approach where the most interested people who are enough experienced are the ones discussing and deciding new features and such, and then whoever wants can develop them, and the pull requests get investigated by the committee or something. That way I think things could be speed up quite well. It is also more rewarding to contribute and fix bugs and make things when your pull requests are accepted sooner rather than later. To get some agility in the development of the project is very needed I think.

Now, this is just my idea on how things could be changed to ease/speed up development of SFML, and I would be glad to take part of such a thing too. But if this is far from what you have in mind, Laurent then I guess it is fair enough to go another way about it. You are the creator of this library after all. :)

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: Rethinking the definition of "Simple"
« Reply #11 on: April 20, 2014, 11:09:17 am »
My dream would be that everyone in this topic join together and actively take over the development of SFML.

Is there any reason this can't happen?

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6286
  • Thor Developer
    • View Profile
    • Bromeon
Re: Rethinking the definition of "Simple"
« Reply #12 on: April 20, 2014, 11:12:49 am »
For example, I can't say that the audio bug discussion went smoothly.
I agree. However, if you check the thread, you'll see that I wanted to hear more arguments to add a feature (and not only fix the bug, which was already decided in the first answer); while Laurent told from the beginning that it was not added because the demand had been too low to make it a high-priority task, which you interpreted as focusing only on newbies and neglecting advanced users. What followed was a general rant against him and SFML, although we said already on page 2 that we consider adding the feature. Even later, when the GitHub issue was long added, it continued.

I think this happened partly due to misunderstanding, general problems with the handling of feature requests and mixing several discussions (is up vector meaningful, is it a feature or a bugfix, what is its best API, why are SFML feature requests handled like this)... But I also see that we could have been more clear from the beginning. I hope by being more open for feature requests in the future we can avoid such flamewars and keep discussions more objective :)
« Last Edit: April 20, 2014, 11:25:31 am by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

therocode

  • Full Member
  • ***
  • Posts: 125
    • View Profile
    • Development blog
Re: Rethinking the definition of "Simple"
« Reply #13 on: April 20, 2014, 12:27:38 pm »
For example, I can't say that the audio bug discussion went smoothly.
I agree. However, if you check the thread, you'll see that I wanted to hear more arguments to add a feature (and not only fix the bug, which was already decided in the first answer); while Laurent told from the beginning that it was not added because the demand had been too low to make it a high-priority task, which you interpreted as focusing only on newbies and neglecting advanced users. What followed was a general rant against him and SFML, although we said already on page 2 that we consider adding the feature. Even later, when the GitHub issue was long added, it continued.

I think this happened partly due to misunderstanding, general problems with the handling of feature requests and mixing several discussions (is up vector meaningful, is it a feature or a bugfix, what is its best API, why are SFML feature requests handled like this)... But I also see that we could have been more clear from the beginning. I hope by being more open for feature requests in the future we can avoid such flamewars and keep discussions more objective :)

Yeah, I agree about the thread and that is your perspective. :P I can find quotes in that thread where it was stated that having the vector accessible etc was too complicated etc, but I don't want to go there. Again, I am not blaming any side or any individual and I don't objectively claim that our side was more right than the other. I just don't think it is purposeful to argue which side on the discussion started with bad things because you'll always hear different things depending on who you ask. Imo such are best left behind and instead it is more useful to work on how to not get there again. :)

I do agree that misunderstandings and both sides getting annoyedly stuck with certain statements and such. But I too am positive that if it would be decided that SFML should be more community-contribution-based, we would be able to forget about old disagreements and kind of "start anew" in terms of discussing the future in a way that most people are happy with. If that is the way the library would go.

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Rethinking the definition of "Simple"
« Reply #14 on: April 20, 2014, 01:29:01 pm »
Hey guys,

nice reading, I have to admit. The most important thing I read was the truth said by Laurent: If things aren't progressing way better than at the moment (only due to lack of time of Laurent, to make my statement clear), then SFML will probably die.

I myself am currently not using it at all due to problems already described in this thread, but as you can see, I'm still lurking around, and I feel kinda "concerned" about what's happening. I just very much like SFML and would hate to see it dying -- but I also dislike the way it has been going the last couple of months.

I like the "committee" idea, formed from people with knowledge, experience and a good contribution-wise attitude ("open source attitude"). The committee's tasks would be to discuss feature requests, review submitted code and set new milestones. Writing code is optional, as I'm sure that there are a lot of people who would be willing to contribute if this lib was more contribution-friendly.

Personally I would join such a committee, and code-wise I would probably try to add automatic testing to the library to reduce the amount of bugs in an automated way.

The really good thing about SFML is its community. I met a whole lot of excellent and nice people, many of which even became friends, and a bunch of them are working on awesome libs after abandoning SFML only due to its limitations. If those people would form a team, then I'm quite sure that this cool library will again follow a path that will enhance it constantly.