Huh? What does this have to do with SFML? What would it be used for? Why in the world should it be part of the core of SFML?
System Requirements slab3d runs under Windows 2000 and higher. For low-latency audio output, slab3d supports ASIO and DirectSound sound device drivers. See your sound device documentation for information on obtaining and installing these drivers. slab3d is developed using the ASIO SDK and the DirectSound SDK. To obtain the ASIO SDK, see www.steinberg.net under Support | 3rd Party Developers. For DirectX information, see www.microsoft.com/directx and msdn.microsoft.com/directx. If executing a slab3d application reports a missing DLL, you most likely require a more thorough version of the "DirectX End-User Runtime" (see the Microsoft Download Center at www.microsoft.com/downloads). The XScape application requires the "Microsoft XNA Framework Redistributable 4.0".
QuoteSystem Requirements slab3d runs under Windows 2000 and higher. For low-latency audio output, slab3d supports ASIO and DirectSound sound device drivers. See your sound device documentation for information on obtaining and installing these drivers. slab3d is developed using the ASIO SDK and the DirectSound SDK. To obtain the ASIO SDK, see www.steinberg.net under Support | 3rd Party Developers. For DirectX information, see www.microsoft.com/directx and msdn.microsoft.com/directx. If executing a slab3d application reports a missing DLL, you most likely require a more thorough version of the "DirectX End-User Runtime" (see the Microsoft Download Center at www.microsoft.com/downloads). The XScape application requires the "Microsoft XNA Framework Redistributable 4.0".
It's Windows only (DirectSound), thus doesn't fit the requirements. Besides OpenAL is the "standard". It's used in thousands of applications and supported on all kinds of platforms, thus it's guaranteed to run stable nearly everywhere.
Might have wanted to dig a bit deeper here. ;)
YSE is basically just a synth and midi player with an audio play API built over JUCE (http://www.juce.com/). And you really don't want to look at their licensing (http://www.juce.com/documentation/commercial-licensing)...
As binary1248 said, the Eclipse license only covers the source code of the YSE library itself and doesn't expand to its dependencies, e.g. you could link YSE statically, but you'd still need to pay for a commercial JUCE license if you'd want to sell your game. ;)
I've split this topic from the other thread, since it started to go way off topic.
SFML also makes use of OpenAL and libsndfile although they both lie under LGPL whereas SFML lies under zlib. As long as the licenses permit using them in those certain ways, nothing prohibits you from doing it. What you can't do is treat those libraries as if they lie under the same license as the library that makes use of them. In the end, your project will directly and indirectly make use of many libraries, all with their own licenses, and you will have to make sure you are using all of them in the ways they allow you to use them.
My guess is, that the author doesn't properly know, how the licensing works and as such he statement on the wiki might be wrong.
Going further, I think he can't even use the Eclipse license on his code, since JUCE is being used (https://github.com/yvanvds/yse-soundengine/blob/master/buildfiles/yse_static_library.jucer#L175) and JUCE falls under GPL (or commercial license) and as we all know, GPL is an infectious license. If you use a GPL library (not LGPL), your code has to be GPL as well.
I don't know, since I'm not a lawyer. ;D
I've no idea, if it would be allowed to claim that this software is developed for the commercial licenses of JUCE and then one wouldn't fall under GPL (ofc it should be mentioned somewhere). If this is allowed, then there's no licensing issue, just missing information.
If it's not allowed, then the question is: Under what does the code now fall. As per JUCE's GPL, it would need to be GPL, so if I were to use YSE right now, under which license would it fall? If it's GPL, then we wouldn't be allowed to strip the JUCE code.
Maybe I got this all of this backwards anyways... I guess I'll create a ticket on the YSE project to clarify things.
Apparently it used to use port audio (which has liberal license) and then switched to juce? ???
The project also migrated to github in the meantime it seems. :P
https://code.google.com/p/yse-soundengine/
Also there is the question of what is the point of SFML audio if this gets in it. What is the point of wrapping a C++, simple to use, rich API in almost identical one? Wrapping OpenAL makes a lot of sense because of the scarrrry C interface that Loki made to reassemble the scarrrry OpenGL C interface (which we also wrap) but this one - I don't see the point. So far SFML is just wrapper/glue code that ties together a lot of C/ObjC OS APIs and few cross platform but very spartan APIs like GL, AL, FT, stbi etc. because it makes (a lot of) sense to make them easier to use, especially the OS windowing/input/context ones which get crazy specific and require a lot of code per platform. AL has only sound output and libsnd is only loading of the sound files so it makes sense these two are tied together by SFML but just dumping one library - a ready, fully featured C++ engine that does everything - into SFML and wrapping it up in a 1:1 wrapper makes no sense to me. It's like wrapping SDL or GLFW in SFML Window and Graphics (which we don't do).
As for 3D audio, I don't know how Irrklang does it exactly (do all OS APIs have 3D?) but it goes down to platform API(ALSA, CoreAudio, etc.) on each platform and wraps them in its' own cross platform API. It's closed source but free for non commercial use.
May I ask what "problem" you guys are trying to solve? OpenAL is native on OS X and iOS, and the only drawback of OpenAL-Soft and its LGPL license is that you can't link it statically, which is a concern only on Windows. But then what's the problem of having this DLL? A program is made of several files (resources, external libs, config, ...) what's so bad with this extra DLL file?
SFML is very unlikely to switch to another audio back-end. If you want to do something useful, you can create your own implementation of OpenAL (*) with a more permissive license.
(*) OpenAL, like OpenGL, is only a specification. It's OpenAL-Soft, its only viable implementation, that we use on Windows and which is LGPL.
[...] I guess I'll create a ticket on the YSE project to clarify things.
My main concern is that LGPL explicit allows for the user of my software to replace OpenAL with a modified version (in this case, a modified .dll), and with that he could maybe leak my game's sound resources.You can't prevent that other than by quitting programming. They have your stuff on their machine. There are tools to peek at programs and data in RAM, there is no way around it.
QuoteMy main concern is that LGPL explicit allows for the user of my software to replace OpenAL with a modified version (in this case, a modified .dll), and with that he could maybe leak my game's sound resources.You can't prevent that other than by quitting programming. They have your stuff on their machine. There are tools to peek at programs and data in RAM, there is no way around it.
There are ways of making it hardSure. But usually, once you attach a debugger it's not that hard. In any case, why bother? Whatever you do, it's going to get ripped/pirated anyway, is your time really well spent trying to prevent that (which you can't anyway).
There are ways of making it hardSure. But usually, once you attach a debugger it's not that hard. In any case, why bother? Whatever you do, it's going to get ripped/pirated anyway, is your time really well spent trying to prevent that (which you can't anyway).
Your platform code argument is still something I don't fully get...
DirectSound or PulseAudio are still just libraries/API. Where these APIs get called by OpenAL or SFML doesn't really help much, in the end someone has to write the implementation for that platform. If the maintainers of OpenAL can focus on that, while ee can deal with other stuff, it's alot better. If OpenAL isn't supported on a platform it's still possible to implement it for that platform and SFML doesn't need to change anything...
This forum has 11111 PostsThirty-one?
I don't know the OpenAL API in detail, but I imagine it is as big and as hard to deal with as the OpenGL API,Not at all. Audio is easy, and doesn't evolve like graphics. So the OpenAL API is relatively straight-forward. The SFML API is a close abstraction of it.
But that is only MY main reason for looking at OpenAL replacements right now, there are other reasons that you guys are just ignoring.What are your other reasons? I couldn't find them (but it's probably me -- sorry).
If you guys are really that averse to allowing multiple audio back-ends I might consider implementing those interfaces on my own code, but I would rather not.We are not against anything, it's just that right now I (and probably others) don't see the benefit of starting this huge work. We rely on a well established and implemented audio API, similar to the one we use for graphics. So far that's perfect for SFML.
QuoteI don't know the OpenAL API in detail, but I imagine it is as big and as hard to deal with as the OpenGL API,Not at all. Audio is easy, and doesn't evolve like graphics. So the OpenAL API is relatively straight-forward. The SFML API is a close abstraction of it.
QuoteBut that is only MY main reason for looking at OpenAL replacements right now, there are other reasons that you guys are just ignoring.What are your other reasons? I couldn't find them (but it's probably me -- sorry).
QuoteIf you guys are really that averse to allowing multiple audio back-ends I might consider implementing those interfaces on my own code, but I would rather not.We are not against anything, it's just that right now I (and probably others) don't see the benefit of starting this huge work. We rely on a well established and implemented audio API, similar to the one we use for graphics. So far that's perfect for SFML.
If the problem is the DLL... (and I can't imagine anything else) look at all the programs installed on your computer. They all use tons of DLLs. Even the operating system is made of tons of shared libraries. Even if we implement something lower-level, it will still rely on DirectSound, ALSA, or whatever libraries that use DLLs. Does anyone care about it?
I'd really like to understand your motivation.
So, are you saying that it would be possible (and even easy) to implement the OpenAL API using YSE, for example? How many and which functions have to be implemented for an OpenAL API compatible library? (Or at least for one compatible with SFML's use of the OpenAL API)
The first would be the possibility of easily porting audio to any platform, even if they don't support OpenAL, by porting only the few low level IO functions. Aside from that, there is maybe the possibility of easily integrating music synthesis and MIDI reproduction on SFML.
About the DLL stuff, I've discussed that on the previous posts. My main motivation would be to prevent the leaking of audio resources.
So, are you saying that it would be possible (and even easy) to implement the OpenAL API using YSE, for example? How many and which functions have to be implemented for an OpenAL API compatible library? (Or at least for one compatible with SFML's use of the OpenAL API)
Not to be rude or anything, but you could have easily looked up a tutorial or two on OpenAL yourself to get at least a vague idea how easy or hard this is before suggesting SFML totally reimplement its audio module. Most of us probably know nothing about YSE so you'd likely get an answer more quickly by researching yourself.
For instance, here's the spec: http://openal.org/documentation/openal-1.1-specification.pdf It's "only" 60 pages, and I found it pretty readable back when I was curious about OpenAL.
QuoteAbout the DLL stuff, I've discussed that on the previous posts. My main motivation would be to prevent the leaking of audio resources.
If I remember your previous posts correctly, it sounds like your threat model is a user who is:Does such a user really exist?
- sophisticated enough to swap out an OpenAL .dll for an alternative implementation of the library that somehow gives him direct access to the sound assets
- but NOT sophisticated enough to somehow locate the sound data in RAM and copy them somewhere else
And assuming they were seriously going to try this sort of attack, couldn't they just as easily go after the even lower-level shared library that they know almost every program on their machine has to use for audio? (ie, the audio drivers?)
It's not clear to me that there's any real benefit to protecting against this.
Incidentally, I'm pretty sure dynamic linking is not the only way to satisfy the LGPL license. It just seems to be by far the simplest, most flexible and most composable method of satisfying it, last time I looked into this stuff. IANAL, but I believe it would be legal to simply make the complete source code of your product freely available online, but none of the assets that go with it (iirc, the LGPL doesn't care about the input or output of the program; gcc has a vaguely similar exception which is why programs compiled with it don't get "infected" by the license). Not quite sure if that helps with your situation, but if it does it might be easier than reimplementing sfml-audio from scratch with a new backend.
I've seen tools that employ highly sophisticated pattern recognition and data mining algorithms along with rudimentary AI to extract all kinds of data out of a frozen process. People can get hold of them fairly easily if they know what to look for.You would still only get the buffer that is loaded (ex: one second of sound). To get the entire resource you would have to do that at every buffer refill (ex: every second), and join them together on the hard drive. That might even not be possible if the sound is being generated proceduraly, but I don't know that for sure.
Just because I've mentioned leaking assets, everyone is talking about that. Since the begginning I've said that that was only my main concernWell... without this main concern, there wouldn't be any compelling reason to consider changing the way things work, so it should naturally be the first thing that gets discussed.
there are other uses to exchangeable back-ends and platform-independent audio computation being separated from low level IO.OpenAL is, just like SFML, a library that sits on top of the raw OS APIs. If SFML wanted to go lower, it would end up writing a sound implementation for every platform that is to be supported, and considering OpenAL does exactly that and much more, why bother going lower?
You would still only get the buffer that is loaded (ex: one second of sound). To get the entire resource you would have to do that at every buffer refill (ex: every second), and join them together on the hard drive.So... where would the data come from? Surely the audio data (encrypted and what not) that is embedded into the executable is somewhere, right? It's even easier to track down where that data is located if the decryption/decoding is done on a periodic basis in order to load a small number of samples at a time. This is probably even easier to do using static analysis of the executable if indeed everything was statically linked.
That might even not be possible if the sound is being generated proceduraly, but I don't know that for sure.Even easier for them to extract the generator code then, right?
If SFML wanted to go lower, it would end up writing a sound implementation for every platform that is to be supported, and considering OpenAL does exactly that and much more, why bother going lower?I have already listed my reasons (LGPL-less, ease of porting for platforms without OpenAL and, for YSE at least, music synthesis and MIDI reproduction). Those might not be enough to justify changing SFML Audio code, but I would definitely work on that OpenAL API wrapper of YSE to keep my SFML code as it is, if the only functions to be implemented are those from this PDF: http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf
Supporting multiple backends "just because we can" hasn't caught much traction, neither regarding audio, networking, or the infamous OpenGL vs Direct3D debate. There have to be substantial benefits that warrant the effort that has to be invested in rewriting the module in question to use a new backend, or even worse to abstract all backends so they can be interchanged at the developer's will.Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.
You simply have to ask yourself: Is it really worth it? Even more so than those big companies that spend millions on content creation? If the answer is yes, please explain to us why. I am sure nobody here can understand as well as you do.For me it is worth spending some time to get what I am after on the audio department, specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach). Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.
ease of porting for platforms without OpenALAnd these platforms are...? Directly from the YSE website:
It runs on Windows, Linux, MacOS, Android and iOS.All these platforms are supported by OpenAL as well... So I don't understand what you mean when you say that more platforms can be supported by an additional YSE backend... In fact, I am fairly sure that you will not get better cross-platform portability from something other than OpenAL. Sure, some platforms won't support it, but often those platforms have their own proprietary APIs that are forced on everyone. I doubt there is a truly cross-platform audio library that supports platforms that OpenAL doesn't.
music synthesis and MIDI reproductionBut this is what I mentioned. Those features aren't part of the SFML feature set, so they can't be considered as a benefit over OpenAL if you are indeed limiting the usage of YSE to the SFML backend and not your own code as well.
Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.More like, Xbox still doesn't officially support OpenGL ;). At some point, when Microsoft notices that their stubbornness is hurting their sales figures, I'm sure they'll be a bit more... "open" to suggestions from the companies supplying the hardware inside the Xbox (who, surprise surprise, are part of Khronos). After all, it's not like the Xbox has specially designed hardware for it, Microsoft just decided not to allow installation of any ICDs on it which prevents the OpenGL API being exposed as well.
For me it is worth spending some time to get what I am after on the audio departmentSo... you aren't going through the same hassle for your graphics (if you have any that is)? "Protecting" graphics from being extracted is nigh impossible since the full dataset has to end up on the GPU at some point, so all I can say is save yourself the time if you are really trying to do that as well.
specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach).I still don't get what you are trying to do... If OpenAL and YSE are so similar in features, surely there is some sort of mapping between the OpenAL and YSE API that allows you to plug YSE in without having to write a compatibility wrapper around it just to make SFML happy.
Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.See... the thing is... the larger the effort that is required to be put into a library, the more it is worth in non-monetary terms. People often don't like giving things away, as you already know. Providing a library for "free" is not equivalent to giving it away for free i.e. without any license restrictions. The license that is often chosen in such cases is a strong copyleft. Instead of requiring you to pay money for the right to do whatever you want with the library, you "pay" by sharing your code with the community in return (in the case of GPL), or in the case of LGPL, you "pay" by promising the developer that any modifications (for better or worse) made to the library are shared back as well, which requires that such modifications can even be made to begin with hence the linking restriction. People seem to forget that before money existed, it was normal for people to trade goods with one another. Obviously, if you had an issue with offering something that someone asked of you in return for something they have, you wouldn't end up trading with them, no matter how much you complain. The same applies to software as well. Closed source projects complaining about the "viral" nature of strong copyleft licenses are for lack of better words, greedy and selfish. They want to benefit from the library without providing anything of interest to the developers (not money obviously) in return. If they want to compensate in money, some projects might allow for dual-licensing, so that is also not an excuse. I really cannot sympathize with them in this regard.
I want to discuss the OpenAL API wrapper thing, specially its possibility of integration to SFML, and I am willing to code the wrapper even if nobody else is, as long as it isn't much trouble.Like I have said multiple times already, wrapping YSE in an OpenAL interface makes no sense if its API can be used directly in the SFML code anyway. Rather than writing the wrapper, you should probably focus on understanding how SFML's audio code works, so you can implement it using YSE if you so desire.
First, can someone (Laurent, eXpl0it3r, or someone else that knows SFML's use of OpenAL) confirm that the current OpenAL Soft API hasn't changed from the Creative OpenAL one on the following link, and that implementing those functions would be enough for SFML Audio to function?
http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdf
$ grep "alCheck(" *.cpp
Listener.cpp: alCheck(alListenerf(AL_GAIN, volume * 0.01f));
Listener.cpp: alCheck(alListener3f(AL_POSITION, position.x, position.y, position.z));
Listener.cpp: alCheck(alListenerfv(AL_ORIENTATION, orientation));
Listener.cpp: alCheck(alListenerfv(AL_ORIENTATION, orientation));
Sound.cpp: alCheck(alSourcePlay(m_source));
Sound.cpp: alCheck(alSourcePause(m_source));
Sound.cpp: alCheck(alSourceStop(m_source));
Sound.cpp: alCheck(alSourcei(m_source, AL_BUFFER, m_buffer->m_buffer));
Sound.cpp: alCheck(alSourcei(m_source, AL_LOOPING, loop));
Sound.cpp: alCheck(alSourcef(m_source, AL_SEC_OFFSET, timeOffset.asSeconds()));
Sound.cpp: alCheck(alGetSourcei(m_source, AL_LOOPING, &loop));
Sound.cpp: alCheck(alGetSourcef(m_source, AL_SEC_OFFSET, &secs));
Sound.cpp: alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundBuffer.cpp: alCheck(alGenBuffers(1, &m_buffer));
SoundBuffer.cpp: alCheck(alGenBuffers(1, &m_buffer));
SoundBuffer.cpp: alCheck(alDeleteBuffers(1, &m_buffer));
SoundBuffer.cpp: alCheck(alGetBufferi(m_buffer, AL_FREQUENCY, &sampleRate));
SoundBuffer.cpp: alCheck(alGetBufferi(m_buffer, AL_CHANNELS, &channelCount));
SoundBuffer.cpp: alCheck(alBufferData(m_buffer, format, &m_samples[0], size, sampleRate));
SoundSource.cpp: alCheck(alGenSources(1, &m_source));
SoundSource.cpp: alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp: alCheck(alGenSources(1, &m_source));
SoundSource.cpp: alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp: alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundSource.cpp: alCheck(alDeleteSources(1, &m_source));
SoundSource.cpp: alCheck(alSourcef(m_source, AL_PITCH, pitch));
SoundSource.cpp: alCheck(alSourcef(m_source, AL_GAIN, volume * 0.01f));
SoundSource.cpp: alCheck(alSource3f(m_source, AL_POSITION, x, y, z));
SoundSource.cpp: alCheck(alSourcei(m_source, AL_SOURCE_RELATIVE, relative));
SoundSource.cpp: alCheck(alSourcef(m_source, AL_REFERENCE_DISTANCE, distance));
SoundSource.cpp: alCheck(alSourcef(m_source, AL_ROLLOFF_FACTOR, attenuation));
SoundSource.cpp: alCheck(alGetSourcef(m_source, AL_PITCH, &pitch));
SoundSource.cpp: alCheck(alGetSourcef(m_source, AL_GAIN, &gain));
SoundSource.cpp: alCheck(alGetSource3f(m_source, AL_POSITION, &position.x, &position.y, &position.z));
SoundSource.cpp: alCheck(alGetSourcei(m_source, AL_SOURCE_RELATIVE, &relative));
SoundSource.cpp: alCheck(alGetSourcef(m_source, AL_REFERENCE_DISTANCE, &distance));
SoundSource.cpp: alCheck(alGetSourcef(m_source, AL_ROLLOFF_FACTOR, &attenuation));
SoundSource.cpp: alCheck(alGetSourcei(m_source, AL_SOURCE_STATE, &status));
SoundStream.cpp: alCheck(alSourcePlay(m_source));
SoundStream.cpp: alCheck(alSourcePause(m_source));
SoundStream.cpp: alCheck(alGetSourcef(m_source, AL_SEC_OFFSET, &secs));
SoundStream.cpp: alCheck(alGenBuffers(BufferCount, m_buffers));
SoundStream.cpp: alCheck(alSourcePlay(m_source));
SoundStream.cpp: alCheck(alSourcePause(m_source));
SoundStream.cpp: alCheck(alSourcePlay(m_source));
SoundStream.cpp: alCheck(alGetSourcei(m_source, AL_BUFFERS_PROCESSED, &nbProcessed));
SoundStream.cpp: alCheck(alSourceUnqueueBuffers(m_source, 1, &buffer));
SoundStream.cpp: alCheck(alGetBufferi(buffer, AL_SIZE, &size));
SoundStream.cpp: alCheck(alGetBufferi(buffer, AL_BITS, &bits));
SoundStream.cpp: alCheck(alSourceStop(m_source));
SoundStream.cpp: alCheck(alSourcei(m_source, AL_BUFFER, 0));
SoundStream.cpp: alCheck(alDeleteBuffers(BufferCount, m_buffers));
SoundStream.cpp: alCheck(alBufferData(buffer, m_format, data.samples, size, m_sampleRate));
SoundStream.cpp: alCheck(alSourceQueueBuffers(m_source, 1, &buffer));
SoundStream.cpp: alCheck(alGetSourcei(m_source, AL_BUFFERS_QUEUED, &nbQueued));
SoundStream.cpp: alCheck(alSourceUnqueueBuffers(m_source, 1, &buffer));
You didn't read my previous posts, or didn't understand them. YSE has all audio processing (spatialization and such) done by software, so the platform code is only related to input/output. That means it is much easier to port only that for a new platform that doesn't have an OpenAL port (lets say, for example, a new embeded hardware), than to port OpenAL.ease of porting for platforms without OpenALAnd these platforms are...? Directly from the YSE website:QuoteIt runs on Windows, Linux, MacOS, Android and iOS.All these platforms are supported by OpenAL as well... So I don't understand what you mean when you say that more platforms can be supported by an additional YSE backend... In fact, I am fairly sure that you will not get better cross-platform portability from something other than OpenAL. Sure, some platforms won't support it, but often those platforms have their own proprietary APIs that are forced on everyone. I doubt there is a truly cross-platform audio library that supports platforms that OpenAL doesn't.
Of course I am considering my code, at least while SFML doesn't implement those features. The OpenAL API wrapper approach would be done to preserve the current SFML Audio code, it doesn't mean I won't use any other feature from YSE.music synthesis and MIDI reproductionBut this is what I mentioned. Those features aren't part of the SFML feature set, so they can't be considered as a benefit over OpenAL if you are indeed limiting the usage of YSE to the SFML backend and not your own code as well.
They are already on their third platform. I don't think they plan on allowing OpenGL, specially because they own DirectX and DirectX is well known and used by many game companies. But again, lets leave this talk for the SFML 3 Vision thread.Well, you have mentioned OpenGL, and there we have a very strong reason to support multiple back-ends: Xbox doesn't support OpenGL. I believe that to be reason enough to try and abstract between OpenGL and DirectX, but lets leave that discussion where it already is: on the SFML 3 Vision thread.More like, Xbox still doesn't officially support OpenGL ;). At some point, when Microsoft notices that their stubbornness is hurting their sales figures, I'm sure they'll be a bit more... "open" to suggestions from the companies supplying the hardware inside the Xbox (who, surprise surprise, are part of Khronos). After all, it's not like the Xbox has specially designed hardware for it, Microsoft just decided not to allow installation of any ICDs on it which prevents the OpenGL API being exposed as well.
I have no plans for that. Graphics code is a hell of a lot more complicated than audio code, and require more hardware acceleration as well, so it gets complicated. On the other hand, I wouldn't know how to extract textures from the video memory of an application, but we are talking about resource leaking again, lets stop.For me it is worth spending some time to get what I am after on the audio departmentSo... you aren't going through the same hassle for your graphics (if you have any that is)? "Protecting" graphics from being extracted is nigh impossible since the full dataset has to end up on the GPU at some point, so all I can say is save yourself the time if you are really trying to do that as well.
How would that work? OpenAL and YSE APIs are very much different, without a wrapper there is no way to just replace one by the other without changing the user's code (in this case, SFML's).specially if I can integrate my modifications with SFML (like with the OpenAL API wrapper approach).I still don't get what you are trying to do... If OpenAL and YSE are so similar in features, surely there is some sort of mapping between the OpenAL and YSE API that allows you to plug YSE in without having to write a compatibility wrapper around it just to make SFML happy.
In this case, I am willing to help improve YSE, since I want to use it. Isn't it better to have more developers (even "closed source" ones) involved with the open source project than to try and dictate what people would do with your code? I participate here because SFML helps me with my coding, and I want to help the project. The same will hopefuly happen with YSE as well.Anyway, I guess I am just still surprised that there aren't any open source libraries that can really compete with OpenAL with a more permissive license. It is not that I am against open source projects (if I do the wrapper thing, it will be open source), but I don't like it when the open source libraries try to prevent "closed source" projects from using them. That is just my opinion, and I respect anyone that thinks otherwise.See... the thing is... the larger the effort that is required to be put into a library, the more it is worth in non-monetary terms. People often don't like giving things away, as you already know. Providing a library for "free" is not equivalent to giving it away for free i.e. without any license restrictions. The license that is often chosen in such cases is a strong copyleft. Instead of requiring you to pay money for the right to do whatever you want with the library, you "pay" by sharing your code with the community in return (in the case of GPL), or in the case of LGPL, you "pay" by promising the developer that any modifications (for better or worse) made to the library are shared back as well, which requires that such modifications can even be made to begin with hence the linking restriction. People seem to forget that before money existed, it was normal for people to trade goods with one another. Obviously, if you had an issue with offering something that someone asked of you in return for something they have, you wouldn't end up trading with them, no matter how much you complain. The same applies to software as well. Closed source projects complaining about the "viral" nature of strong copyleft licenses are for lack of better words, greedy and selfish. They want to benefit from the library without providing anything of interest to the developers (not money obviously) in return. If they want to compensate in money, some projects might allow for dual-licensing, so that is also not an excuse. I really cannot sympathize with them in this regard.
Given what I have just said, you will find that any kind of highly complex library is often proprietary or strong copyleft. They aren't things that people can do in their spare time like SFML is, hence they want their time to end up being worth something more than their own personal enjoyment.
If I do that, I would be dropping SFML Audio entirely. I have code using SFML Audio, so insted of porting all my code, I would rather code an OpenAL API wrapper, so that more people could use it and I could keep my SFML code as it is now.I want to discuss the OpenAL API wrapper thing, specially its possibility of integration to SFML, and I am willing to code the wrapper even if nobody else is, as long as it isn't much trouble.Like I have said multiple times already, wrapping YSE in an OpenAL interface makes no sense if its API can be used directly in the SFML code anyway. Rather than writing the wrapper, you should probably focus on understanding how SFML's audio code works, so you can implement it using YSE if you so desire.
Thank you! If those are all of the OpenAL functions called by SFML, they are all on that PDF. I will analyze the YSE code now, to know how much trouble I would have to strip JUCE and replace it with a library with a more permissive license for the IO functionality on the main platforms.First, can someone (Laurent, eXpl0it3r, or someone else that knows SFML's use of OpenAL) confirm that the current OpenAL Soft API hasn't changed from the Creative OpenAL one on the following link, and that implementing those functions would be enough for SFML Audio to function?
http://open-activewrl.sourceforge.net/data/OpenAL_PGuide.pdfCode: [Select]...
1. Don't forget that you can use your own statically linked OpenAL-Soft, instead of the one SFML provides, if your own code is LGPL.My own code is closed source.
2. More platforms: OpenAL-Soft already does what you describe, if you want to port SFML to more platforms then the solution is just to write a new platform back-end for OpenAL-Soft.Sure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are right.
3. OpenAL wrapper for YSE: you'll end-up with an OpenAL implementation, what difference would it make then?I would be able to create a simple interface for the platform specific code inside YSE, would be free from the LGPL license and would have YSE ready for using any of its other functions. Those reasons are enough for me to at least try to implement the wrapper.
4. MIDI synthesis: it will most likely be added soon as a sfml-audio plugin (I've found libraries that can convert MIDI and other tracker formats to sampled audio).Nice to hear it! You were once concerned about the libraries size, did you find some alternative for the big instrument base?
Sure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are rightI'm not talking about the OpenAL API. It's implemented in OpenAL-Soft, fine. I'm talking about the internals of OpenAL-Soft itself: it already has a smaller subset of platform specific functions for low-level input/output. You would just have to port these functions to make it work on a new platform. No need to reinvent the wheel.
would have YSE ready for using any of its other functionsNot through SFML, then?
You were once concerned about the libraries size, did you find some alternative for the big instrument base?No, one still has to somehow get the instrument database to play MIDI, whether it is installed by default on his system or copied with the musics. But it would be an optional plugin (maybe not even official), so it wouldn't be shipped with the precompiled SFML libraries.
Sure, but then the library would still be under LGPL.QuoteSure, but the OpenAL API, although small, is still a pain in the ass. I think it would be just easier to implement some simple IO functions for the platform, but you are rightI'm not talking about the OpenAL API. It's implemented in OpenAL-Soft, fine. I'm talking about the internals of OpenAL-Soft itself: it already has a smaller subset of platform specific functions for low-level input/output. You would just have to port these functions to make it work on a new platform. No need to reinvent the wheel.
Yes, or at least until SFML implements them.Quotewould have YSE ready for using any of its other functionsNot through SFML, then?
Why dont you stop arguing already Tex Killer? You painted yourself into a corner and by endlessly repeating the same disproven arguments you will make yourself only look worse without ever being able to convince people of doing unnecessary free work. Just change your own code to use YSE or whatever.I am not trying to convince anyone to do anything anymore. I will be the one trying to strip JUCE from YSE and wrapping it with the OpenAL API.
Btw., isn't YSE using JUCE and with JUCE beeing GPL your own code would be linking indirectly with GPL code instead of LGPL OpenAL soft? This would mean you would be "worse off" and need to open source your code, as GPL doesn't even have that dynamic linking exception. :PJUCE is being used mainly for low level audio input/output. That can be replaced by a compatible library with a more permissive license, and I think it would be rather easy. I am still yet to analyse the code to have a better notion of that.
YSE is not an audio back-end, it's merely a highlevel API over JUCE and JUCE does the hard work. Just replacing OpenAL with YSE or writing a OpenAL API wrapper for YSE won't solve anything regarding licesing issue, in fact it would get even worse due to JUCE being GPL. Thus one first needs to replace JUCE, which will not be an easy thing, especially for all platforms.From what the developer of YSE has told me, JUCE is being used for the low level audio input/output only, so I believe that it would be easy to replace it with another library with a more permissive license. It used to have PortAudio for that (when it was on google code), so that could be an option.
If you really think about replacing JUCE with the OS APIs for YSE, then you'll very soon realize that this work is not something we want to do and maintain in SFML itself, thus 1) won't happen.That last suggestion is what I am trying to do here (except maybe the OS API calls). Did you read my last posts? I will try to first replace JUCE with a library with a more permissive license, then wrap YSE with an OpenAL API. SFML wouldn't have to change anything if I manage to do that, I would just replace the OpenAL implementation it uses.
As for 2) what's the point? There's no comparable library out there, as such you'd have to write your own (say you adapt YSE) and thus you'd essentially implement all the OS API calls (like OpenAL already did), just to end up with a different high-level API. Wouldn't it be waaaay smarter to use the standardized and well-known/used API (i.e. OpenAL specification) and simply write a new implementation for it, which you then can release under whatever license you'd want?
If there's really a platform which doesn't support OpenAL, it would still be a lot better to modify OpenAL itself, instead of investing days of work to get a library that supports all the platforms OpenAL supports + the one you want to support. Then the whole OpenAL user base could benefit from it as well. Analogically if you notice that you missed a feature in your library code, you don't go and throw the code away and start from scratch, but you simply add it to the existing code base. ;)I don't know if that is allowed. It would certainly stop the casual players from replacing the DLL, but I think the object files have symbols from the code, so that would be even worse. I'm not sure, I would have to research more about that, and if it is allowed by LGPL.
As for LGPL and linking. The way I understood the license is, that you can link it however you want. The only thing you have to guarantee is, that a newer/different version of the LGPL licensed library can be linked. Thus you could also just provide the object files of your application, so someone can link in a newer version of OpenAL. Of course this would still allow for linking modified versions of OpenAL.
If you're concerned about asset leaks through library replacements/injections, then you'd probably would have to talk to the drivers directly or even write your own driver, because as shown above, e.g. OpenAL on Windows uses DirectSound, which again is a library that can be replaced and DirectSound uses WinMM, which again is a library that can be replaced and depending on your driver, the driver might also be built as library and would thus be replaceable, etc... ;)I have talked enough about that. Replacing DirectSound would get you the mixed output sound only, not the individual assets. Taking assets from RAM would be possible, but one would have to take it buffer by buffer and join them together. Anyway, lets stop discussing this.
As binary1248 indicated, playing around with the RAM is rather easy with the right tools, so you're largely misjudging the difficulty of one vs the other task.
And when it comes to GPU memory, things get even easier. Not to mention the numerous DirectX or OpenGL injectors out there.
I believe that libsdnfile does that, right? You guys said that you've found a suitable alternative for it. Can you tell me what alternative is that?
I believe that libsdnfile does that, right? You guys said that you've found a suitable alternative for it. Can you tell me what alternative is that?
Based on this commit to the relevant feature branch (https://github.com/SFML/SFML/commit/b9c10a3b0487f0ab13c6e70257b24d754ac6e5c8), the plan appears to be using libraries like libogg and libvorbis.
WAV is straight-forward, I implemented it directly. Don't hesitate to look at the source code of this branch if you want to know more about how the various formats are implemented (FLAC has not been pushed yet, I'm still working on it).