SFML 3 - What is your vision?

[Laurent]

Are you going to make SoundFile public?

Exactly.

[Hanmac]

what i would like:

• Adding Thor ParticleSystem & Animation: but try to add DefaultConstructor and setter methods, the thor classes does miss them
• adding more sound formats, specially midi, might be pluginable for other stuff like gstreamer, pulseaudio or JACK
• if thinking about Video, a render video to RenderTarget would be fun
• Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewport
• sf::Shader add way to get the type of a parameter from the program if possible
• does SDL2 have something we might need?
• Have Styleable Text where TextSections can be styled differently
• add more samples, specially from the new features, but i would also like to see the SoundListener features in action

[Laurent]

Adding Thor ParticleSystem & Animation

SFML is a multimedia library, not a game library
So let's keep these more advanced concepts in add-on libraries like Thor.

adding more sound formats, specially midi, might be pluginable for other stuff like gstreamer, pulseaudio or JACK

This is something that we'll consider with the new sound file system.

if thinking about Video, a render video to RenderTarget would be fun

The main blocking point about video is the huge list of dependencies needed, their license and their build system (yes, I have ffmpeg and all its codecs in mind).

Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewport

This is a bit too high-level.

sf::Shader add way to get the type of a parameter from the program if possible

I don't think if OpenGL gives this option, and I have no idea why one would have to do that. You're supposed to know what types you've declared in your shader...

does SDL2 have something we might need?

SDL 2 is always an interesting source of inspiration, but we'd like to avoid "please implement X because SDL has it"

Have Styleable Text where TextSections can be styled differently

This is also a bit high-level in my opinion. You can easily make your own with what SFML provides.

add more samples, specially from the new features, but i would also like to see the SoundListener features in action

Feel free to provide a more detailed list of what you'd like to see

[binary1248]

sf::Shader add way to get the type of a parameter from the program if possible

I don't think if OpenGL gives this option, and I have no idea why one would have to do that. You're supposed to know what types you've declared in your shader...

This is also the reason why interface blocks were introduced in GL 3.1. The idea is that you declare a shader with a specific interface in mind, which you of course have to reflect in your code. Multiple shaders (even shader stages) can implement the same interface block if they are to be accessed in the same way from the user code. You are the one who writes the interface, for both sides. So anybody writing a custom shader that should work with your code will have to abide by it.

On a side note, I think certain engines/frameworks actually go ahead and perform very thorough inspection of shader code before passing it on to the GL. This is to provide a lot of advanced features that SFML really shouldn't try to cover, of which uniform type inspection is also one. This can probably be implemented in an extension library for SFML if someone really wanted to.

Just a note for all future posters: The main idea is to add features to SFML that extension libraries (like Thor, sfeMovie, SFGUI) wouldn't be able to implement because of a limitation within SFML itself. They are built on top of SFML and provide higher-level functionality as Laurent already said. Suggestions here should be targeted towards lower level things that have to be in core SFML to be made accessible to said higher-level libraries or your own code.

[Hanmac]

Adding Thor ParticleSystem & Animation

SFML is a multimedia library, not a game library
So let's keep these more advanced concepts in add-on libraries like Thor.

oh ok i didn't consider it "game libary" only stuff, i thought that would be basic enough for multimedia lib

Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewport

This is a bit too high-level.

Dammit ok it might be but as far i dont know if it can be emulated with addons for sfml, like binary said:

The main idea is to add features to SFML that extension libraries wouldn't be able to implement because of a limitation within SFML itself.

currently i dont know if it can be done with extension libraries

does SDL2 have something we might need?

SDL 2 is always an interesting source of inspiration, but we'd like to avoid "please implement X because SDL has it"

i looked myself what we could need ... SDL2 has gamecontroller support (we only have joystick, that might be a bit different), otherwise i didnt find anything what we might need.

Have Styleable Text where TextSections can be styled differently

This is also a bit high-level in my opinion. You can easily make your own with what SFML provides.

hm okay if its simple to make it might be able to add to thor or similar,
i thought it would be low enough (simple enough) for SFML

add more samples, specially from the new features, but i would also like to see the SoundListener features in action

Feel free to provide a more detailed list of what you'd like to see

i might look what i can do ... mostly currently i am thinking how to combine sf::Sprite with sf::SoundSource
(and maybe with some kind of LightSource too? i was thinking about some fireplace where you could get near)

[Laurent]

Dammit ok it might be but as far i dont know if it can be emulated with addons for sfml

I don't know what it is in detail, but if it is a chain of full-screen effects then this can easily be achieved with two sf::RenderTexture.

[marcf3]

I don't think it has been mentionned before, but adding audio effects and more fine-grained control would be great. It seems to me that the area is often lacking features :p

As the graphics API supports shaders, it would be nice to be able to (at least) apply audio filters to create reverberations, echos, convolutions, 3D effects etc. 

I agree to the need for loop points too, especially when streaming audio. Also, if possible, an option for low-latency playing of streamed sounds (preload first chunks on openFromFile())?

[binary1248]

As the graphics API supports shaders, it would be nice to be able to (at least) apply audio filters to create reverberations, echos, convolutions, 3D effects etc. 

This isn't as easy as it seems . sf::Shader is built on top of OpenGL shaders. They make use of an own language: GLSL. OpenAL isn't really comparable to OpenGL in that it isn't hardware accelerated and as such doesn't have an equivalent for filters to entail something like an ALFL . And if there isn't any free and compatible (license-wise) library to perform filtering, I don't think it will make it into SFML any time soon.

[marcf3]

I remember there is an EFX extension to OpenAL that handles some effects. But if it can't be hardware-accelerated, could software post-processing be achieved (like many audio softwares do) as well by the ability to write filtering code before the samples to be sent to OpenAL?

[binary1248]

As I already mentioned here, this belongs to the class of "features" that can be written on top of SFML without making any changes to its core. sf::SoundBuffer already gives you access to the samples of the audio it contains and you are free to modify and reload it back into the buffer after you are done, either in your own code or using an external library.

Most audio processing libraries are proprietary from what I've seen, so there is a very slim chance something like that would make it into SFML if you take what I said above into account as well.

[marcf3]

Ok, I understand for hardware...
For software effects, I actually meant "real-time" ones, those we could tweak while the sound is playing. I don't know how it would be done for sf::Sounds since they are entirely uploaded to OpenAL before playing. But for streams, it would need to override onGetData() and perform the effect before returning the chunk. However, there is a SoundFile class here that is not exposed to the API ^^"

[binary1248]

If you want to modify the data while it is in-flight, then the data is really a stream. For this sf::SoundStream exists. It is even explained that you would want to derive from it to implement your own class that streams data from whatever source you want, including a filter you wrote:

sf::SoundStream is a base class that doesn't care about the stream source, which is left to the derived class. SFML provides a built-in specialization for big files (see sf::Music). No network stream source is provided, but you can write your own by combining this class with the network module.

As far as I can tell, everything you described can be achieved with the current API...

[marcf3]

It is even explained that you would want to derive from it to implement your own class that streams data from whatever source you want,  including a filter you wrote

I know, but a filter wouldn't be a source here, just some code between the raw samples and the filtered samples. The real source would be a file, and since the SoundFile wrapper is not exposed, it's difficult to stream them simply. I could use sf::SoundBuffers as in the tutorials, but it's not file streaming.

[binary1248]

But if using an sf::SoundBuffer in conjunction with its loadFromStream() method to partially load in samples to filter for an sf::SoundStream isn't considered streaming, what is for you? You can interface any sort of file stream that adheres to sf::InputStream with an sf::SoundBuffer.

[marcf3]

How can I tell how many samples to load with soundBuffer.loadFromStream()? It seems to me that it loads the entire sound data too (from a file or a stream that contains an audio entity), and already sends it to OpenAL with alBufferData(). Or am I missing something?
By "audio streaming", I really mean to read a part of an audio entity and play it while the next part is loaded chunk by chunk, wether it is from a file or a C++ input stream (it's a bit ambiguous I guess).