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

Author Topic: SFML 3 - What is your vision?  (Read 193585 times)

0 Members and 1 Guest are viewing this topic.

Phanoo

  • Full Member
  • ***
  • Posts: 136
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #270 on: October 07, 2014, 08:07:15 am »
My vision of SFML is a SFML that follows developer's needs ;D
« Last Edit: October 07, 2014, 08:20:48 am by ratatax »

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #271 on: October 07, 2014, 08:44:49 am »

Critkeeper

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #272 on: October 10, 2014, 01:06:13 am »
Disclaimer:
I'm not a heavy SFML user, I'm not a software professional, I am not even sure I am above the median skill level in the ordered set of skill levels across all users of SFML for this library or game programming in general. I'm just a college student studying software engineering and I tinker with SFML when I can find the time to, and the only complete game I've ever made was a dinky arcade shooter in java that was implemented badly.

That said, from the perspective of someone who's judgement isn't clotted by familiarity and predisposed bias for what SFML is or how "simple" it is, whether in an absolute or relative sense, I have a few opinions about what SFML of any version should be. For those who would dismiss my opinion because I don't fully appreciate the functionality of the current SFML, and assume that this disqualifies me from making general assumptions about the philosophy of SFML, I apologize that I can't be any more constructive or helpful to you or this community.

I only have one significant request for SFML, and that is stratification. By that I mean the complexity and functionality of the library should be stratified. A small subset of its current functionality designed to be as approachable as possible even to people who have zero experience with media handling of any kind and limited experience with programming, could be called Strata 0 SFML, or "Simplest fast multimedia library".

Strata 1 could be for people with moderate experience with multimedia programming and probably contain the functionality that SFML currently contains. "Simpler fast multimedia library".

Strata 2 would be for people who want the most power that they can get with a reasonably succinct API, and would be "Simple fast multimedia library".

The point is that it isn't possible to satisfy everyone with a single library because some design directions are mutually exclusive or atleast mutually inverse, like power and simplicity; furthermore the "perfect balance" for one class of users may not be the same "perfect balance" for another class of users.

I may be mistaken, but stratifying sfml won't fracture your user base or triple your work load as developers IF you CAREFULLY choose how implement it. The question comes down to this:


What is the set of things most of your novice users need out of SFML? What is the preferred ratio of power / simplicity?

What is the set of things most of your average users need out of SFML? What is the preferred ratio of power / simplicity?

What is the set of things most of your advanced users need out of SFML? What is the preferred ratio of power / simplicity?

The first set should be a subset of the second, which should be subset of the third. Obviously if it is possible to replace elements with an equal number of elements that can create more power for basically no decrease in simplicity for any class of users ought to be followed. And if it is possible to replace elements with a fewer number of elements for no decrease in power for any class of users ought to be applied universally to SFML regardless of strata.

But apart from that general design philosphy, what is considered an acceptable loss of power for an increase in simplicity, or loss of simplicity for an increase in power is contingent on the preferred power / simplicity ratio of the Strata in question. It may be that we want to reduce the functionality of a lower strata in order to increase simplicity for example. Furthermore, ensuring that the a subset of things in a lower strata are not subsumed by smaller set  which is NOT a subset of the next higher strata is important because users would generally expect that if they master a lower strata then they should be able to transition to a higher one without "unlearning and relearning"  because there exists concepts that are incompatible between the two strata-- there should be no such incompatibility.
if(CritKeeper.askQuestion()){return question.why();}

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10193
    • View Profile
    • development blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #273 on: October 10, 2014, 03:41:49 am »
Thanks for presenting your view! I really like opinions that aren't clouded by some judgments and aren't just "make it do X", meaning they have more depth to them.

While your idea sounds well logical, I can't really imagine how this would work from an API perspective. Would we have three different APIs where one builds on top of the other? Or would we simply define these "stratas" in the tutorials? Do you have an example of an API that does this?

Besides that, you bring up a good point and that is, we can't have just the good from all the worlds. And it's essentially this balance I wanted to figure out in this thread. By hearing what changes people want to see, we'll try to figure out how far over the advanced line we can push SFML and check whether we can raise the entry level.

However one thing I wouldn't really want to see is Strata 0. Sure we won't be able to prevent it, but for the most time it's really just a lot of wasted effort when people try to use SFML without being able to program the most basic things. We've developed and maintain a library and aren't here to hold introduction to C++ or programming talks. There are dedicated communities which do this kind of thing to some form and they are usually way better equipped with information and teaching material.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Cornstalks

  • Full Member
  • ***
  • Posts: 180
    • View Profile
    • My Website
Re: SFML 3 - What is your vision?
« Reply #274 on: October 10, 2014, 07:09:57 am »
However one thing I wouldn't really want to see is Strata 0. Sure we won't be able to prevent it, but for the most time it's really just a lot of wasted effort when people try to use SFML without being able to program the most basic things. We've developed and maintain a library and aren't here to hold introduction to C++ or programming talks. There are dedicated communities which do this kind of thing to some form and they are usually way better equipped with information and teaching material.
This. SFML is written in C++. C++ is not Java/C#/Rust/Scala/Racket/Haskell/Python/JavaScript/etc. It doesn't hold your hand. It gives you a loaded gun, and lets you do whatever you want with it, especially shoot yourself. It's important to keep the target audience in mind: C++ developers. These developers might have a wide range of skill and experience levels, but if they're using SFML and C++, then 1) they aren't (or shouldn't be) total novices to programming, 2) they're in it for the pain, and 3) they're prepared to deal with the fact that they might (and eventually will) blow their leg off. While I think SFML should be as simple and user friendly as possible, it shouldn't coddle users who are woefully unprepared for the tools they're using.

I personally would like to see an SFML that changes the "Simple" from meaning the library is a bare-bones, minimal simple library, to a "simple to use, and simplifies your life" type of meaning. As FRex said, sometimes things move in the "simple to read, simple to write, hard as f**k to use because you need to write 5 helpers for everything" direction. I don't want SFML to be bloated and contain the whole kitchen sink. But I do think many SFML users reinvent the wheel just to use SFML, and I'd like to see more of those redundancies handled in the library.

So I guess I'd like SFML 3 to take the approach of: what to many users do with/to SFML to simplify their life in using it, and how can those common things be incorporated back into SFML?

Ixrec

  • Hero Member
  • *****
  • Posts: 1241
    • View Profile
    • Email
Re: SFML 3 - What is your vision?
« Reply #275 on: October 10, 2014, 08:10:35 am »
@Critkeeper

To me it seems like SFML already has a lot of implicit stratification, even if there are no formal tiers. For instance:
- Drawing stuff: Use sprites and textures -> Use vertex arrays for batching or custom shapes -> Raw OpenGL
- Playing audio: Load from file and play -> Twiddle the bits in a sf::SoundBuffer yourself -> Raw OpenAL
- Text: Use sf::Text -> Use sf::Font and sf::Glyph and create the sprites/vertices yourself -> Raw Freetype

What I didn't see in your post was any particular reason why formal tiers would be a good thing or (as eXpl0it3r pointed out) what formal tiers would actually mean.  Simple, simpler, simplest isn't really a definition.  The tutorials already make it fairly clear which features are advanced and which aren't.  I can't think of any sweeping statements/guarantees we could sensibly make about one tier and not another (at low tiers...less exception safety? the user manages memory themselves? the user manages contexts themselves?), and I can't come up with any restrictions we would ever want to place on only certain tiers or the interaction of tiers (eg, it makes perfect sense to use sprites/textures alongside vertex arrays and/or raw OpenGL).

Did you have any concrete ideas about how a formal "stratification" would be different from the current SFML or what specific benefits it would have?

Critkeeper

  • Jr. Member
  • **
  • Posts: 62
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #276 on: October 10, 2014, 11:23:33 pm »
One example of explicit stratification would be a "marquee" interface / abstract class which doesn't exist in strata 0, does exists in strata 1, and perhaps exists with additional switches and options in strata 2.

The interface or abstract class would be inherited by the Sprite and Text classes. Its function is to provide the programmer a way indicate that a specific texture or text should be clipped to a small rectangular region, and that the region is what is being drawn. You could use the state of the marquee to scroll the text side to side or to indicate that the space should be a loop like what you might see on big LED signs that advertise various things. You could also set the state to scroll continuously or discreetly and be commanded by time or call-- so you could implement a sprite sheet with the marquee system, or you could create a very long and narrow sprite that represents hundreds of projectiles and just loop it as described above for looping text.

In strata 1 it would include finer control, so that the region that it is drawn onto isn't specifically a rectangle, but can be any user defined shape and pair of edges belonging to that shape to form a "ribbon". There might be more rendering control so that people can create layered special effects using hardly any texture space or any more overhead than it takes to change local view space coordinates and do some clipping and "stretching" on the texures.

Now that isn't something I necessarily need in SFML or probably something that most people need. I'm just giving an example of what stratification is.

The point is to make MASTERING sfml easier by reducing the skill curve. You reduce the amount of options and you also reduce the complexity. Then people can master a subset of the functionality of SFML proper, and when they are content with that and really are being held back by the lack of options they can move up one stratification level and learn more things and do more things. That increases the rate at which newbie users develop into expert users.

The Stratas do not have differing design philosophies, they just have different audiences. Strata 0 does not try to provide a way to do everything with enough effort, it is supposed to provide an extremely simple interface for doing simple things that allow you to "get a feel" for what SFML is and what the higher stratas do in the general sense.

People who are experts with SFML or who are practicing software engineers probably could just read the documentation and know pretty much instantly what SFML is capable of. What I'm saying is that it isn't necessary to limit your audience because you can have your cake and eat it to. You can please everyone. You can have power for those that want power and simplicity for those that need simplicity above all else, just by stratifying your API. The cost of that design direction is the same as the cost of splitting your userbase into 3 parts, or subcommunities. If there isn't enough motivation in one subcommunity it can fracture the userbase and cause the "pipeline" to fail.

In order to prevent that from happening you would just need to carefully consider what each sub community needs from a media library and carefully design the stratification to meet the needs of the user base. That means writing software for the consumer rather than software for the sake of fulfilling a philosophical idea of what "simple" ought to be.

If software can bring people together, cause them to want to instruct eachother, communicate a tangible sense of achievement (through stratification), endow a sense of responsibility, and be powerful enough to do everything the user could want while being concise enough for the user to comprehend then people will use it regardless of what the word or idea "simple" really means.

As for HOW stratas are implemented, whether by having one API be a subset of another or just artificially through the tutorial is something I consider an implementation detail. It doesn't matter how such a thing is implemented as long as the implementation is effective and it actually organizes the community into discreet classes of users.

The fact is that newbies who ask questions some times get answers that they can't understand because the person answering them presumes an understanding about many different things, when a simple and less accurate explanation which is atleast comprehendable would be infinitely more useful. People iterate. They learn, unlearn, and relearn until they approach an understanding that represents the truth. Giving someone a terse answer that you worked for 3 years to understand may not be appreciated, and this causes a communication breakdown between these classes of users.

By putting people into classes of other people who have roughly the same familiarity with the API, they can work off of eachother's expertise by providing answers and questions that everyone in that subcommunity can understand. By putting incentives to higher strata communities to answer outstanding questions or problems that the lower strata community cannot resolve on its own, you build a positive flow, where some users in a lower community eventually become practiced and familiar enough with one strata to master then next higher one and to contribute to the associated next higher sub community.

The increase in the total number of "SFML Masters" due to the increased flow can cause a wider and more impressive variety of things to be created by SFML users, which can draw in more "newbie" users, and what you have is like a social version of a jet engine where the faster you go the more air you take in and the faster you go.
« Last Edit: October 11, 2014, 12:03:20 am by Critkeeper »
if(CritKeeper.askQuestion()){return question.why();}

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1404
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 3 - What is your vision?
« Reply #277 on: October 10, 2014, 11:58:17 pm »
The point is to make MASTERING sfml easier by reducing the skill curve. You reduce the amount of options and you also reduce the complexity. Then people can master a subset of the functionality of SFML proper, and when they are content with that and really are being held back by the lack of options they can move up one stratification level and learn more things and do more things. That increases the rate at which newbie users develop into expert users.
Isn't that what makes games great? Being easy to learn and hard to master? Given that SFML doesn't aim to keep people "playing the development game" longer than they want to, I don't think it is necessary to give people a "virtual milestone" where they can claim that they have mastered some aspect of SFML. Who knows... maybe they might think that they have mastered something, when in fact they are far from it. As such any such "virtual milestone" doesn't make much sense to me, and gives people more of a reason to falsely assume that they have completed something that has no clear completion conditions.

It might sound like I am implying that you can't master SFML no matter how hard you try, and maybe that has a bit of truth to it. In the end, all software development libraries and languages are nothing more than a means to an end. You resort to them to get things done, whether for fun and/or profit. If people pick SFML up solely as a challenge that they intend to "complete" one day, then power to them, but that is very atypical. If you ask me, it doesn't make sense to give people a reason to claim they have mastered anything in software development. It is not up to them to judge if they have mastered something, it is up to others.

What we should do instead is focus on ways to let people get what they want done faster, both in the short and long term. In the short term, they would find SFML, hopefully read the tutorials and documentation and be able to figure out how to combine things to make what it is they want to make. These people are the ones who probably end up asking really trivial questions on the forum on a daily basis, and are angered when we don't provide them short-term solutions (i.e. copy and paste ready). The people who are interested in getting stuff done in the long term are the ones that read the tutorials, documentation and other forum posts and who are happy for non copy and paste ready feedback. They understand that we are trying to help them improve their practice for the future as well.

If you ask me stratification doesn't solve either of these cases. The short term users will still venture beyond what they are currently comfortable with, and the long term users will treat everything as a single stratum anyway. Dividing it up according to what we think makes sense will end up annoying us as well as the long term users, and the short term users won't even acknowledge that such strata exist anyway.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Lolilolight

  • Hero Member
  • *****
  • Posts: 1232
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #278 on: October 25, 2014, 12:05:11 pm »
Here's my vision :

-A system which allow us to choose between the use of an implicit opengl context, or an explicit opengl context.
-A common interface which allow us to use any library of any os for the different modules by redefining some methods of a common interface used by SFML. (I think that a system to load .dll or .so files on linux and to choose a module to use is a good way.)
So if SFML is not supported by an os we can integrate it easy.

-Support for multiple screens. (It was already proposed and it's already in the program)
-Support for embedded systems. (It was already proposed and It's already in the program too.)

No more visions for the moment but if I've another ones, I post here.

Turbine

  • Full Member
  • ***
  • Posts: 102
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #279 on: November 11, 2014, 02:19:21 pm »
More general purpose functionality, such as a fully fleshed vector class.

Gambit

  • Sr. Member
  • ****
  • Posts: 283
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #280 on: November 11, 2014, 02:23:47 pm »
More general purpose functionality, such as a fully fleshed vector class.

SFML is a general purpose multimedia library, and by extension, the vectors are also general purpose. The vectors in SFML do not necessarily have to be used for mathmatical purposes.

Kojay

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #281 on: March 02, 2016, 05:31:17 pm »
*bump*

Hope you don't mind me bumping this to bring up a (spontaneous) idea on the age-old radians vs degrees issue.

Already, passing a float as an angle leaves a bad taste, considering C++'s emphasis on types. It would be much more fitting to have a type for it.
Doing that would make it trivial address the degrees vs radians issue by an overload.
Furthermore, thanks to the user-defined literals that SFML 3 will be able to use, it will be possible to write something like

rotate(90_deg);
rotate(1.5708_rad);
 

preserving the simplicity that was Laurent's original intent.
(although unfortunately that last bit doesn't seem to work with the M_PI macros).

Feel free to shoot it down.

The strong type safety itself is important in my view.

addendum: Come to think of it, it's already possible to introduce two types without breaking the API, by making Degrees implicitly convertible to from float, while Radians not.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6275
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML 3 - What is your vision?
« Reply #282 on: March 03, 2016, 12:16:25 am »
@Klaim: We have already discussed those points here -- a bit of time has passed since then though ;)

There I explained why I consider different angle types and corresponding function overloads a bad idea. User-defined literals can be helpful, and they would work with a sf::Angle class as well.

If you feel there's really something new to add to the discussion, please use the other thread, so we have things in one place. But as mentioned, I believe we've already covered that part -- and don't worry, I won't forget about it :)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Kojay

  • Full Member
  • ***
  • Posts: 104
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #283 on: March 03, 2016, 02:38:40 am »
I am not Klaim >:(

Thanks for pointing me to that topic - I suspected that people would have thought of these things but failed to find that one.
On first impressions, I agree with sf::Angle. I 'll be sure to add any further thoughts there.

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6275
  • Thor Developer
    • View Profile
    • Bromeon
Re: SFML 3 - What is your vision?
« Reply #284 on: March 03, 2016, 09:08:28 pm »
Damn sorry, your ideas sounded so similar that I totally overlooked that ;)
(especially at that late hour)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

 

anything