SFML 3 - What is your vision?

[Laurent]

setSize in which class?

[Peteck]

- Support for multiple monitors.

I'm curious, what do you mean by multiple monitor support? :-)

[eXpl0it3r]

I'm curious, what do you mean by multiple monitor support? :-)

Currently it's not possible to specify on which monitor a window should be created. Actually SFML doesn't even "know" that there are multiple monitors, it always just assume the primary monitor is the only monitor in existence.
I guess "multi monitor" can be split into two categories:

• Provide the possibility to choose a monitor to create a window on and retrieve resolution infos from different monitors, etc.
• Make it possible to create "windows" across multiple monitors.

I'm sure the first part will get into SFML at some point, while for the later I've no idea how it works and what would need to be done.

[Kojay]

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  )

I concur. Yes it is possible to accomplish with the existing tools but the same could be said of the other shapes. First of all, lines drawn as vertex arrays with the primitive "Lines" are 1 pixel thick and stand apart from other shapes. Then if you decide that you want a line with thickness instead, you switch to rectangle shape - an 'implementation change' that is not seamless. In both cases you 're writing boilerplate; all in all, the absence of a LineShape has always been a very odd omission.

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).

Guessing that setSize is from 1.6. setScale() does have such an overload, if anything however I would argue for its removal. One of the strengths of C++ is its emphasis on types, this kind of overloads defeats it. Moreover, in C++11 you may write

setScale({x,y})
 

[Laurent]

Yes, these overloads will probably be removed when we switch to C++11.

[Zephilinox]

I'd like Sprite Batching, the ability to modify the style/colour of substrings of sf::Text, and a way of setting an outline for sf::Text.

A Line class would be nice too, I think it was removed from a previous version, I guess for performance issues? Would spite batching resolve those issues?

I'd also like to see more work done on the other areas of SFML, like Audio and Networking, which are generally forgotten. Though I have no specific suggestions in mind. I don't feel like there are any good frameworks out there for audio and networking that are both easy and simple.

[MorleyDev]

Well UPnP support would be nice for Networking, but I'm not exactly holding my breath for it.

Though with the Android/iOS release, a simple cross-platform UPnP would be neat. Allow for things written in SFML that can detect other players on the WiFi like Minecraft Mobile does.

[Ganado]

@Kojay
Wait, I still don't get why doing that overload is a bad thing. Why not have give the option to write it either way?

[Nexus]

Why not have give the option to write it either way?

Having only a vector overload encourages people to use vectors instead of separate components, which is generally a good thing. Also, it is more consistent with the rest of the API... unless you want every function to take separate components, but then also colors and rects.

[Kojay]

@Kojay
Wait, I still don't get why doing that overload is a bad thing. Why not have give the option to write it either way?

Type safety is one of C++'s crown jewels. If you mean to pass a vector, pass a vector. See this presentation by Bjarne Stroustrup:

http://youtu.be/0iWb_qi2-uI?t=19m7s

It's true these overloads are present in several libraries for ease of use - Qt employs them exensively. But with C++11, there's no excuse.

[Tex Killer]

Hey guys...

I've been away from the forum for a long time, so I'm sorry if these issues were already taken care of.

The issues I wish were addressed by SFML3 (if not already) would be:

1) Clipping masks, or some way of having polygon-shaped views (http://en.sfml-dev.org/forums/index.php?topic=9877.msg67745#msg67745)
2) Audio listener rotation support (http://en.sfml-dev.org/forums/index.php?topic=7995.0)
3) Optional MIDI support as add-on of instrument banks, that could be plugged to SFML if there was need for it (http://en.sfml-dev.org/forums/index.php?topic=7079.msg46850#msg46850)
4) Support for custom loop points for the audio module, or a way to achieve it without having to hack SFML's sources (https://github.com/SFML/SFML/issues/177 and http://en.sfml-dev.org/forums/index.php?topic=6213)

Thanks

[Ixrec]

I believe #2 actually happened (https://github.com/Foaly/SFML/commit/a9096c04cbfa5626c6cb5ee661c3287f8755a0ce) and #4 came very close to happening (https://github.com/SFML/SFML/pull/629).  Dunno about the others.

[Laurent]

4) Support for custom loop points for the audio module, or a way to achieve it without having to hack SFML's sources

This will at least soon be possible without hacking into SFML sources, with the coming modifications to the audio module.

[Arvamer]

I want only joystick force feedback.

[Tex Killer]

My understanding is that https://github.com/SFML/SFML/pull/629 is not integrated on SFML, right?

If it is just one implementation made by users, I've already coded one for my engine and have been using it for a while. I've made a version of it avaliable here: http://en.sfml-dev.org/forums/index.php?topic=6213

Laurent, how will it be done without hacking into SFML sources? Are you going to make SoundFile public?