SFML 3 - What is your vision?

[infinitebox]

Doesn't even the SFML tutorial say that you should use C++ 11 threads where possible? If SFML 3.0 makes C++11 fully required, then I could see why it's being removed-

You are right. Personally I use std::thread and have never used sf::Thread.
I think I confused sf::Thread with some other API that exposes functionalities such as setting priority, and pause and resume
The sf::Thread's delayed thread launch looks nice though.

[therocode]

Things I really want:

• Enhanced math library (more vector/matrix stuff, up to 4D, and including things like quaternions)

IMO there are absolutely no reasons to add advanced maths stuff since there are other libraries doing that and being focussed on it. GLM for example is headers only and has heaps of functionality related to 3D graphics maths. Adding a maths module to SFML would only mean more maintenance and reinventing the wheel.

[Lambert]

Simple and Fast Multimedia Library

By downloading and using such named thing, I would expect simple and fast coding. SFML is one of few good libraries known to me that support full OOP (and by fully I mean it's really simple to use, for example Qt is unintuitive, especially with main function design), which is insanely helpful. However your library should be scalable. It should be as good for newbies as for pros. That's why you should add simple demos and free stuff for first-time-use. Some free music, textures etc. Also default font would be nice improvement. I never understood why original author didn't include it.
 
As it goes for pros, I think that adding 3D support is obligatory. I don't know any fully OOP libraries (with such good API as SFML) supporting 3D and it isn't so hard I think, it just need good packing OpenGL functions into classes and a bit of optimization.

Native supports for widgets. I know I can import another library or create my own GUI, but neither is simple nor fast.

As it comes for C++11 and C++14 I don't see any reason to not make them obligatory. Compilers that won't support these features when SFML 3 would be released will be greatly outdated and there is no reason to outdate SFML itself because of it.

Advanced functions, like mentioned above mathematical operations on vectors in etc. should be also included. "Fast" means for me not only that program itself will be fast, but also that I won't have to waste my time looking for additional dependencies, while "Simple" means that everything what is needed to create game or application (from programming side ofc, not resources) will be provided to me in an easy, simple way. It won't affect library efficiency as everything is modular and I include only these files I want to include.


Worst you can do is to expect people to install hundreds of additional libraries to make their games and apps work, just because "they can do it". We are not talking about SFML 2.x, but SFML 3 and it's long-time project, so there is no reason to reject any idea just because it's "time wasting" and "it is already done in XYZ library".

[Nexus]

That's why you should add simple demos and free stuff for first-time-use. Some free music, textures etc. Also default font would be nice improvement. I never understood why original author didn't include it.

There are many code examples to show the various parts, so what do you mean? SFML provided a default font in earlier versions, but it was removed (if you're interested in the reasons, search the forum, there was a discussion about it).

[therocode]

Worst you can do is to expect people to install hundreds of additional libraries to make their games and apps work, just because "they can do it". We are not talking about SFML 2.x, but SFML 3 and it's long-time project, so there is no reason to reject any idea just because it's "time wasting" and "it is already done in XYZ library".

By this logic you would expect SFML to ship AI, state management, path-finding, physics, scenegraph management, dynamic resource loading, a whole set of GUI components, astrophysics simulation, car assembly algorithm, face recognition, and who knows where we'd stop.

SFML is a multimedia library, not a game development suite. I don't believe there are enough developers to cover up for all the time and management that would be needed if SFML would greatly increase its scope. Also, just because SFML doesn't include everything does not make you need "hundreds" of dependencies. You only need to grab the ones you want.

I would rather see that time is put into refining what the concept of SFML is, make the API great, extend its feature set within the scope and do it well like no other multimedia library out there.

[Cornstalks]

IMO there are absolutely no reasons to add advanced maths stuff since there are other libraries doing that and being focussed on it. GLM for example is headers only and has heaps of functionality related to 3D graphics maths. Adding a maths module to SFML would only mean more maintenance and reinventing the wheel.

I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.

[Njifra]

Hmmmm... Maybe there should be enum sf::DriverType, something like in Irrlicht 3D Engine...

Definition:

enum DriverType
{
        OpenGL,
        DirectX9
};
 

Usage:

window.create(sf::DriverType::OpenGL, ...\*other params*\);
 

I can help with it(if help is needed) since im expirienced with DirectX9...
Please reply

[zsbzsb]

You are talking different backends, this isn't as simple as you think and would require a complete redesign of SFML internally.

[therocode]

I'm not asking for the whole kitchen sink (I said "enhanced," not "advanced"). The thing is SFML already provides vectors and matrices. And these aren't things that can be stripped out of SFML, as coordinates and transforms need to be specified for SFML to do its work. But these things SFML provides have no support for basic linear operations (dot/cross products, projections, etc.). It would be nice if common operations and data types (i.e. quaternions, particularly if 3D support is added) were supported.

Still, it seems to me that SFML's math classes are there to make SFML work on the inside, not to provide advanced maths functionality to the user. If maths is needed in your project it is still super easy to grab GLM, it is a very light dependency being headers only.

Although, in my opinion the best alternative would be to discard the SFML maths classes and instead use GLM directly. That way you can do all the maths you want and it would still integrate well with SFML and you would not have to rewrite a lot of maths.

[Njifra]

You are talking different backends, this isn't as simple as you think and would require a complete redesign of SFML internally.

Thats why I offered my help. Im making multimedia library with DirectX and I did almost everything(except sound). Now im working on mesh loading. So im pretty sure I could help(if its needed xD).

Soon, my lib will be SFML's rival

[stoleks]

multimedia library with DirectX

In fact I don't see the point of using DirectX (especially with an obsolete version like directX9, I'm not very familiar with directX, but this version is almost 6 year old, no ?), and in my mind OpenGL is faster and cross platform (perhaps I'm wrong..).

[Njifra]

DirectX 10 and 11 also exist.
DirectX 12 is coming soon.

[Ixrec]

I guess we'll need DirectX if SFML ever gets ported to the Xbox and Windows Phone.

Maybe in SFML 10.

[NoobsArePeople2]

I feel that SFML 2.x does a good job of covering the basics. Want to open a window? Use the keyboard and mouse? Draw some stuff to the screen? All that stuff just works and is simple to use. I'm not saying these things can't be improved but I feel that the core of SFML is pretty good.

I think one place where SFML drops the ball a bit is when it comes to scenarios that aren't clearly part of the core of a multimedia library. Another problem is that SFML becomes a lot less simple once you start on a non-trivial app.

For example, it's simple and fast and easy to load up a texture and display it with a sprite but once you start having a lot of sprites and performance falls into the gutter you have to fall back to sf::VertexArray and really get your hands dirty in managing all your sprites to optimize drawing, which is pretty low-level and not something typically characterized as "simple" . Adding something like sf::SpriteBatch that would take sf::Sprites as children could allow for quick an easy batching of draw calls reducing the friction of using SFML for a common task.

The things I'd like to see are about expanding utility and making SFML simpler and easier to use as apps become more complex.

• C++11 required.
• "System Info" Class: a class to get information about the current system at runtime. I'm thinking things like OS name, OS version, RAM, CPU, GPU, etc.
• A mouse disconnect event. This one might seem odd at first but think of people using wireless mice or laptops where peripherals or more regularly attached/dettached
• Sprite batching. This is a pretty obvious win for drawing performance and while it can be achieved via sf::VertextArray it would be a lot simpler and user-friendly to be able to batch sf::Sprite out of the box. link to Cocos2D sprite batch for an example
• Support for texture compression. This is more of an actual concern for Android/iOS and a "nice to have" for desktop.
• Support for texture atlasing. Like sprite batching this is another obvious win for drawing performance. Texture Packer is one such tool SFML could support. It supports Custom exporters so SFML could have its own tool-independent format.
• Actions and Easing. Essentially the ability to manipulate the properties of objects over time. See example.
• More support for 3rd Party Tools. This would depend on the addition of new features first but I think it's worth considering. Examples include Texture Packer, Glyph Designer, Particle Designer (or Particle Editor for non-Mac folk), and I'm sure there are plenty of others.

These are community related but I think worth mentioning for a "vision" of what SFML can become:

• More solicitation for community contributions. A coding style guide, an intro README, and a sub-forum specifically for discussing contributions are a couple suggestions for fostering more community support.
• Maintain a list of contributors. It's always nice to give people who help you out their due Having some sort of licensing agreement for contributors might be a good idea as well (sample link).

Another thing that I think would be informative is to try to find people who have used SFML in the past but moved away from it for one reason or another. Finding out what lead them to drop SFML for ____ will likely shed some additional light on SFML's deficiences. You might have to look them up and contact them directly but I do see people in the forums and github tracker stating things along the lines of, "oh, it's cool you finally fixed this but I've since switched to SDL."

[Canadadry]

You are talking different backends, this isn't as simple as you think and would require a complete redesign of SFML internally.

You can use ANGLE to do that, Qt is using it to provide OpenGL ES or DirectX on Windows http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL

I also like to have some of QML (from Qt) capabilities ie : (Which are also present in JavaFX take a look)

• A Scene Graph (with basic positionner container like column, row, grid)
• Anchors
• Animation (property, tween, easing ...)
• Multi-Touch and Basic Gesture (pinch, multi finger tap and swipe)

For game purpose I see everyone re-developping the same thing :

• TileMap rendering
• Sprite Batching
• Entity System
• Particules
• Improving sf::Text with metric, alignement and true multi ligne

This is the few thing I've been rewriting over and over again from the past years, for every game I made.
To illustrate the SceneGraph stuff take a look at one of my last project I'm working on https://github.com/Canadadry/PineApple/blob/master/src/main.cpp