SFML 3 - What is your vision?

[MorleyDev]

Perhaps we can elaborate what changes are exactly needed to make this happen.

Of the top of my head:
The Windowing API would need to support EGL, GLFW or SDL 1.2 for creating windows.
The Graphics API needs to support the WebGL subset of OpenGL (which is a subset of OpenGL ES 2).
Audio API.
Networking would need porting to WebSockets/WebRTC. Probably easier to drop support of it for Emscripten.

[therocode]

Perhaps we can elaborate what changes are exactly needed to make this happen.

Of the top of my head:
The Windowing API would need to use GLEW to create the window and handle events without any OS specific code (or at least the OS specific stuff is #ifdef'd away).
The Graphics API needs to support the WebGL subset of OpenGL (which is basically OpenGL ES 2).
Audio API.
Networking would need porting to WebSockets/WebRTC. Probably easier to drop support of it for Emscripten.

GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2. Many OpenAL functionalities are supported out of the box by emscripten. Events and windows can be managed using SDL's API out of the box and that could be written as a backend for the window stuff. Networking I have no knowledge about.

[MorleyDev]

GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.

Damnit Brain-fart, GLFW. not GLEW xD argh, those aren't confusing similar names at all

As I understood it you have to use EGL (+X11), GLFW, or SDL to create a window for OpenGL. I edited to list them, but doesn't SFML already use GLFW in parts?

Also the Android port I'm guessing uses EGL, so there's already that code available.

[eXpl0it3r]

I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML...

[therocode]

GLEW or any manual extension loading is not required for emscripten. All supported GL calls work out of the box. The graphics API needs to be ported to work with OpenGL ES 2.

Damnit Brain-fart, GLFW. not GLEW xD argh, those aren't confusing similar names at all

As I understood it you have to use EGL (+X11), GLFW, or SDL to create a window for OpenGL. I edited to list them, but doesn't SFML already use GLFW in parts?

Also the Android port I'm guessing uses EGL, so there's already that code available.

Aah, then it makes sense and yeah you need to use them to create a window, but that can be separated easily into a backend probably. Not sure about GLFW in SFML.

I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML...

No, not as a dependency. Emscripten provides that automatically when you compile using it. So you would use the SDL/GLFW API in the emscripten backend as an underlying base for window/event stuff and then you can compile it with emscripten. No need to grab or install SDL or anything.

[eike]

Hi,

* I vote for C++-11
* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.
* a technique to insert an event (example: my_triple_mouse_click) to the event loop
* timer events

[Nexus]

* a technique to insert an event (example: my_triple_mouse_click) to the event loop

Why would you need that? You can easily have a custom event queue on top of SFML's...

* timer events

Can you elaborate?

[select_this]

I'll also throw my hat in for using C++11 where possible, for what it's worth.

I'd like to see some 3D getting in too - not for me, specifically, since I'm a sucker for rolling my own stuff, but because I have a sneaking suspicion that the user base of the library would grow significantly.

Support for more file formats would be great as well. Other than that, I don't really have anything specific to add.

[MorleyDev]

I'm a bit confused. What role is SDL playing in this all? Because I don't think it's really an option to have SDL or GLFW as dependency of SFML...

You don't need to link them, Emscripten does that automatically. So they're just another part of the #ifdef chain. Emscripten doesn't specify most of it's own window creation functions (it all gets compiled down to canvas HTML and Javascript in the end), but hijacks/reuses a few existing and common cross-platform libraries to provide the hook between canvas and code. There are some emscripten does provide, like getting the size of the canvas.

Going away from Emscripten, C++11. C++11. All of the C++11.

And maybe the ability to hook into the file loading to add custom type support.

[infinitebox]

* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.

sf::thread, maybe.
Removing sf::clock is definitely a no no for me. It's a useful utility class and provide higher precision than VC12's std::chrono::high_resolution_clock due to the library not using native high precision API.

* a technique to insert an event (example: my_triple_mouse_click) to the event loop
* timer events

These could all be done by implementing your own event system on top of SFML's event facilities, which would be more flexible and far superior for your game logic needs. I think sf::Event should be kept to what it is now, for window and input related events.

[eike]

* a technique to insert an event (example: my_triple_mouse_click) to the event loop

Why would you need that? You can easily have a custom event queue on top of SFML's...

There is a little overhead in adding an own event queue. Just call window.pushEvent(myEvent) would be nice.

* timer events

Can you elaborate?

Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on. I know, that these things can be done by a thread or checking for the clock every iteration. But I think, that would by a nice to have.

// start timer numer 3, just once after 60 ms
timer3.start(60, false);

...
    if (event.type == sf::Event::Closed)
        window.close();
    else if(event.type == sf::Event::Timer)
    {
        // which timer?
        // do something
    }
...

[MorleyDev]

There is a little overhead in adding an own event queue. Just call window.pushEvent(myEvent) would be nice.

If SFML were to implement a more complex event system, it would be prescribing more details about how the consumers of SFML are to interact with it. Allowing generics to be pushed onto the system would require a callback system of some kind.

Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on.

There are other C++ libraries that provide this functionality, and implementing it yourself is not difficult but details are quite dependent on your own current system. Whilst the OS does provide some timer behaviour SFML could hook this into, it seems like a 'Game Framework' feature, not an SFML feature, to me.

[AxelRantila]

* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.

sf::thread, maybe.
Removing sf::clock is definitely a no no for me. It's a useful utility class and provide higher precision than VC12's std::chrono::high_resolution_clock due to the library not using native high precision API.

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-

I haven't worked with C++ standard library clocks, but I really think that the sf::clock class should stay

[Rosme]

Lets say, you would like to close a window after some seconds, check for network after some time, save a game state on disk every hour and so on.

There are other C++ libraries that provide this functionality, and implementing it yourself is not difficult but details are quite dependent on your own current system. Whilst the OS does provide some timer behaviour SFML could hook this into, it seems like a 'Game Framework' feature, not an SFML feature, to me.

Plus, if SFML goes full C++11, std::bind, std::function and lambda makes it really easy to do this. And if really you don't want to do it yourself, you can always use Thor TriggeringTimer

[Cornstalks]

Things I really want:

• C++11 (non-optional) (C++14 is cool and all, but would have very little impact on SFML's API)
• Pure OpenGL ES 2.0 back-end
• Support for OpenGL ES 3.0 context creation (particularly on Android)
• Enhanced math library (more vector/matrix stuff, up to 4D, and including things like quaternions)
• Improved HiDPI support (across all OSes)
• The context stuff mentioned earlier
• Focused on multitouch rather than mouse
• Multiple windows
• More platform introspection (# of logical and physical cores, CPU/GPU type, etc.)
• Radians, not degrees
• (Not related to SFML 3, but would be nice to pair with it) Forums that support markdown

Things that would be awesome (but that I can live without):

• Web/emscripten back-end

Things that I think are cool ideas, but I haven't thought about enough to think if they're bad ideas:

• Basic 3D graphics support
• SSL/TSL/SSH support i.e. HTTPS, SFTP, etc.
• Bluetooth support
• File I/O stuff? Perhaps just until C++17