SFML 3 - What is your vision?

[ast]

In rhythm based games it would be important to know with reasonable accuracy what sample is playing right now. If I recall correctly there was some difficulties with that.

Otherwise, I would second what has proposed in a few other messages in this chain that it would be great if there would be more higher level stuff for typical game creating purposes. Not included directly in SFML but with additional libraries that would be shipped with SFML or recommended as to the default way of doing things. Thor would clearly be one of those. Actually this looks like a separate project that would build on SFML.

[siordache94]

I'm checkin this post every other day !
Any updates / dev on the 3rd version of SFML ?

[Hammer55]

One feature I believe would be a great addition is the ability to change the style of the cursor, including options such as hand, waiting, pointer and text selecting. This fits under the S mainly because the concept is obvious and easy to understand at a high level, setCursorStyle(sf::CursorStyle Style). At the low level however this requires using system APIs, which can be difficult to test across multiple operating systems. If you were to do this by simply hiding the cursor and drawing seperate icons you would have consistency issues and SFML drawn cursors and basically any non OS based cursor always lags behind the OS cursor.

It would make it possible to give users consistent cursor styles that go with whatever theme and OS is in use. Being able to do this would be an opportunity to make most GUI elements much more intuitive.

[Hiura]

This is being worked on. https://github.com/SFML/SFML/pull/827 

[scellow]

For SFML 3.0 i hope you'll still maintain the C# binding :p


It would be nice to have extended features for Vectors, like Lerp/Distance, and an official tweaning api would be great addition i think

EDIT:

Console support would be cool too :p

[zsbzsb]

For SFML 3.0 i hope you'll still maintain the C# binding :p

Of course that will still happen. 

It would be nice to have extended features for Vectors, like Lerp/Distance, and an official tweaning api would be great addition i think

Highly unlikely as that is a high level API, but everyone can dream... 

Console support would be cool too :p

What do you mean by that?

[Kiecker]

Personally I LOVE SFML, it is a very simple api with many different uses in the OpenGL scene and does stand as a strong competitor against SDL (whose only advantage is very nice cross-platform support).

However I would like to see
  - Some of the compatibility we do see in SDL, SFML does work against all pc platforms but I would love to use   some of these tools when making android games as SFML has some of the best sprite handling in my opinion
  - This is just a small gripe of mine but if you could getting rid of having to use the different configs with .lib / .a files when there are 2 sets of libraries that are generated. Sadly in that sense that is a win for SDL
  - Some bug fixes with using SFML Textures in OpenGL, this might just be me but when I use sf::Texture::bind() on some objects in opengl there will be an error message in the console that says there was an opengl

however these are all small complaints as SFML is one of the simplest and well documented libraries out there and I can't wait to see how you change it in the future.

[Laurent]

- Some of the compatibility we do see in SDL, SFML does work against all pc platforms but I would love to use   some of these tools when making android games as SFML has some of the best sprite handling in my opinion

SFML already works on Android and iOS.

- This is just a small gripe of mine but if you could getting rid of having to use the different configs with .lib / .a files when there are 2 sets of libraries that are generated. Sadly in that sense that is a win for SDL

I'm not sure I understand what you mean here.

- Some bug fixes with using SFML Textures in OpenGL, this might just be me but when I use sf::Texture::bind() on some objects in opengl there will be an error message in the console that says there was an opengl

I don't think bug fixes belong to the "vision for SFML 3" thread
If the bug has already been reported, then it should be scheduled for a 2.x release. If not, then please open a new thread where you describe your problem.

[korczurekk]

What about getting rid of overriding huge amount of methods like that:
sf::Transformable::move(float x, float y)
sf::Transformable::move(sf::Vector2f vec)
?

With C++11 second one is enough, as you can use brackets to initialise structure:

sprite.setPosition({100, 200});

SFML's code would be much shorter and easier to maintain.

[Laurent]

What about getting rid of overriding huge amount of methods like that:
sf::Transformable::move(float x, float y)
sf::Transformable::move(sf::Vector2f vec)
?

Yes, we already mentioned this point.

[korczurekk]

Okay, sorry but I was too lazy to read all those (20?) pages. 

[korczurekk]

Maybe remove sf::Time? std::chrono can fit it's position well and you'd have much less code to maintain.

I searched for phrase "time" and didn't find it, sorry if it's a duplicate.

[Balnian]

I kind of agree with korczurekk SF:Time could be replaced with std::chrono
But if we go further we can also remove :
sf::Threads => std::thread
sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)
sf::sleep => std::this_thread::sleep_for
sf::Clock => std::chrono::high_resolution_clock
sf::FileInputStream => std::ifstream (literally the same)
sf::InputStream => std::istream (literally the same)
sf::Lock => std::lock_guard (literally the same ... again)
sf::MemoryInputStream => if sf::InputStream become a std::istream we won't need this anymore
sf::Mutex => std::mutex
...
Well a good part of System could be removed in favor of a Standard implementation 

Also when will the SFML 3 project/branch be started?

[victorlevasseur]

sf::FileInputStream => std::ifstream (literally the same)
sf::InputStream => std::istream (literally the same)

I don't know if we can use the i(f)streams with Android and iOS, that's probably why they were created.

Also when will the SFML 3 project/branch be started?

Same question for me. I would really like to participe in SFML 3 development.

[Mario]

I don't know if we can use the i(f)streams with Android and iOS, that's probably why they were created.

You can, but not to access assets bundled with the app.