SFML 3 - What is your vision?

[G.]

It'd be nice if there was a way to make it so window.draw() could take a std::vector of sf::Vertex

?
It already does. It's even shown at the end of this chapter in the vertex array tutorial. :p

[myl]

Maybe it's time to introduce the SFML Video module? I'm not even sure it would be that much work if based on ffmpeg

Shouldn't video playback be a basic component of a Simple and Fast Multimedia Library ?

myl

[Jebbs]

Maybe it's time to introduce the SFML Video module? I'm not even sure it would be that much work if based on ffmpeg

Shouldn't video playback be a basic component of a Simple and Fast Multimedia Library ?

myl

I've always thought the same. I feel like video playback is definitely in the scope of a multimedia library. I think I remember seeing the reasoning behind it once, but when and where escapes me.

[Laurent]

Yes, I think it would fit. But ffmpeg (which is the only reasonable backend to implement such a module), is a huge dependency, and apparently a pain to build.

This can be investigated though. We have a former member of the SFML team who has already developed such an extension (sfeMovie), that could be a good starting point.

[Lolilolight]

Ha yeah it would be nice for games cinematic and history.
Can't wait until SFML 3. 

[Syntactic Fructose]

Some C++11/14 integration would be pretty cool to see in SFML  . I've been a huge fan of the project since it's birth, and would love to be able to give a talk on SFML in the upcoming C++Now 2015 or Cppcon 2015

[Jabberwocky]

My SFML 3.0 priorities would be:
1.  continued focus on porting to new platforms
2.  performance enhancements (batching, atlases, etc)

I'm excited about the mobile device ports.  Anything that might help out with a console port would be equally awesome.  There's been a pretty big push from the console makers (especially PS4) to become more indie inclusive.

Thank you Laurent and the SFML Team for your great work.

[Jabberwocky]

Lower priorities, but still worth consideration would be:
1.  Particles
2.  Animation

I see Thor offers both these, but I haven't looked into it too much yet.

I think Particles would just be an overall win, and would find widespread use among SFML users.

Animation is tricky, because different folks will want to do it differently (e.g. sprite sequences vs 2D skeletons).  I suspect a lot of advanced users may end up coding their own anyway.  Still, a simple default implementation might do a lot to further increase the popularity of the library.

[Ruckamongus]

There really should be a way of managing the requests better. Personally I have the problem that I quickly lose overview in a forum, because current stuff gets mixed with old stuff. And once you have read the threads marked with "New posts!", it's difficult to remember what's still important and what not.

Just like with this thread: One has to go through *all* posts for collecting all the ideas etc. GitHub's issue tracker would work, however then ideas would be mixed with actual issues, which is not an option as well.

I agree to Nexus that a 100% free-form voting would end up in SFML becoming a 2D game engine with a world editor, tons of effects and a class "sf::GameGenerator" -- probably not what this library is intended for. However a mixture might be interesting, i.e. feature requests are made, everybody discusses them, based on arguments it's accepted or declined, and if it's accepted, people might vote for influencing priority/severity (is that what you meant, binary1248?).

Tello might be something worth looking into. Here's the feature tour and an example:
https://trello.com/tour
https://trello.com/b/nC8QJJoZ/trello-development

[infinitebox]

Tello might be something worth looking into. Here's the feature tour and an example:
https://trello.com/tour
https://trello.com/b/nC8QJJoZ/trello-development

This might work!

Nate, the author of Spine (a skeletal 2D animation tool for games) uses it for the Spine editor and runtimes. There are several running list of tasks/features and stuff that he's working on and everyone can comment and vote for features.
https://trello.com/b/dle5mTBW/spine-runtimes
https://trello.com/b/frGlgsF7/spine-editor

[Juhani]

As promised we as the new team, would like to be more open towards the community especially regarding the current development. We're currently discussing on how to approach things after SFML 2.2 and as such, we need to figure out what SFML 3.0 should actually be about.

Keep in mind this shouldn't really be about simple feature requests, for that we have dedicated forum, this should be more about what SFML 3 should offer besides a few new feature. For example: How the graphics API should be changed/opened/advanced, or whether C++11 should be non-optional, or should we change the way window states are handled, or etc...
We won't make any decisions here, we simply want to hear the ideas from all community members.

What is your vision of SFML 3?

Basically all computer programs receive information and send information; just the source/destination varies. The source may be user input (not just mouse+keyboard, but microphone and webcam), any mass storage, the clipboard or something else. The destination may be the monitor, speakers, printer, any writable storage, the clipboard, or something else.

SFML's job is to provide a simple & fast multiplatform interface to receive that information, and send it. That's what I call a multimedia library.

I don't see a reason to avoid C++11 if that is useful.

[Jesper Juhl]

Add this to what I've already posted as my 3.0 wish-list:

- IPv6 support.
- Support for multiple monitors.
- Use of modern OpenGL.
- HTTPS support.

[achpile]

All I want is a Line class >.<
Yup, the line is a rectangle shape with height = 1, but everytime I need to draw line, I have to calculate length and angle =)

(It was too hard to draw lightnings with rectangles  )

[eXpl0it3r]

Depending on what exactly you want to do, you can also just use a vertex array with the primitive type "Lines" or "LinesStrip".

[Ganado]

Very small feature:
Just as a sf::Transformable has a setPosition(float x, float y) as well as a setPosition(const sf::Vector2f& position),
it'd be nice if the setSize(const sf::Vector2f& position) function could also be setSize(float x, float y).