Messages

16

General discussions / Re: Clipboard support on Linux: A few hiccups.

« on: October 11, 2014, 08:25:48 pm »

Sure, use a window handler on Windows too, but I believe that is an implementation detail. Why should it affect the API? What is so bad about creating a dummy window if there is no Window already created?

17

SFML development / Re: SFML Context Management

« on: October 03, 2014, 09:08:49 pm »

What I understood from previous posts is this: OpenGL uses contexts to manage render targets, and those contexts are not "safe" for multithreading, so they have restricted each context to a single active thread. You can deactivate one thread and activate another, but you can't have two active threads on the same context, so in other words it just forces the user to do the synchronization.

All that is important to know, I already mentioned in the list in the original post. You can multi-thread with contexts safely, you just have to keep those constraints in mind. Instead of activating and deactivating threads, which I never talked anywhere about, you activate and deactivate contexts. Even if a thread is "inactive" whatever that means, if a context is still active on that thread, it won't be able to be activated anywhere else. You have to consider things from the context's point of view and not the thread's point of view.

I meant to say that you can deactivate a context on a thread and activate it on another thread, but you can't activate it on multiple threads at the same time. I though it was obvious, but sorry for the bad wording.

My suggestion is that the synchronization is done hidden inside SFML, so that the API can stay the same.

This is the way it currently is, and if you've read what has already been posted in this thread again, you will see that this leads to problems. And before you say anything else, no, your solution will not solve any of these problems. It will merely create more of them.

I know it is already like this, that is why I've said that the API would stay the same. What I am discussing here is possible implementation changes that could solve the said problems without affecting the API.

I didn't know we had to synchronize data retrival functions as well. As I've said before, I only know this issue from what I've read here, so if I don't know all of the problems my suggestions will be flawed from the start. How does data retrieval work on OpenGL? Is it thread-safe? Does it support parallel data retrival on multiple threads? Does it use the contexts for that? In what way? I am realy clueless to this point.

Data retrieval isn't as complicated as you think, but that still doesn't mean you don't have to give it a bit of thought. It can have many manifestations. The most common and simple one is getting a single state value from the driver. This can be different depending on which context is active when you call the respective function. For things like taking screenshots, it is a bit more complicated. You will have to pass in a correctly sized array so that the GL can write the data you request from it into the array. This is also context dependent, and is a rather slow operation since we are reading data directly from the GPU.

Ok, the data depends on the active context, so we have to synchronize data retrieval as well. That could be done by blocking the calling thread until the "drawing thread" retrieves the data, and sharing the return value between threads, but I agree that it is not as clean as it could be.

If you heed what I said in the original post in regards to contexts and threads, then yes, it is thread-safe. Yes it supports parallel retrieval on multiple threads, also constrained by the same requirements. Yes it uses contexts, everything in OpenGL uses contexts, didn't you read the original post?

If it uses the active context, it can't be used in parallel. Or am I missunderstanding something? If you can't have two different threads retrieving data from the same context at the same time, I wouldn't consider it thread-safe, but that might be bad wording, so I am sorry for the missunderstanding. In the end, we have to synchronize drawing and data retrieval functions to the same context ourselves.

This is worse than I expected... Now I understand that you were aiming to have a separate "rendering thread" for each context that can be used in some way... just so you can omit having to constantly select which one to activate? There are beginners on this forum... that just start out with game development, and after not too long, even they understand that having more threads than necessary is not a good thing. I don't know where you are coming from, but if you think that resorting to creating an excessive number of threads to get anything done is a good idea, I am sorry to have to tell you that you are mistaken. The same is said to beginners as well as advanced developers: Avoid threads while you can. Unless you know exactly why they provide a benefit, you won't gain much from them.

Ok then, lets avoid multiple meaningless threads. I'll suggest another solution at the end of the post that doesn't create any aditional thread.

If that is the case, then you must also oppose usage of smart pointers over raw pointers too right? Raw pointers don't create unsolvable issues and have better resource usage than smart pointers, and yet the universal opinion from any established C++ programmer is that you should rarely ever use raw pointers (and certainly not owning ones) in modern C++ code.

Using raw pointers directly is much harder than using smart pointer. It is bad practice because unless you pay attention to all of the allocation and freeing of memory, you will create serious problems. Sure, if you don't pay attention to the synchronization of OpenGL operations it will create serious problems, but as long as we manage to take care of those problems internally, it will cease to be bad practice to the final user. If SFML used raw pointers on some internal sections of code, for example, but used them correctly, the user code wouldn't be affected by it in the least. The user wouldn't even see the pointers.

Ok, it is unheard of, but would it work?

You tell me... I am not going to go ahead and spend 10s maybe even 100s of hours implementing something I find problematic from the start. From reading what you have proposed, I would say, yeah, it can work, but have fun with your 2 FPS applications. Ultimately, most ideas in software development, no matter how crazy they are, can be implemented. You just have to spend a varying amount of time dealing with the effects you did not anticipate during brainstorming.

I still fail to see the reason for the drop in performance. Sleeping threads shouldn't affect the performance of the active threads. Anyway, I'll suggest another solution at the end of this post, please take a look.

What are the possible drawbacks? Is the number of threads limited to less than the number of possible contexts on an application? Would multiple sleeping threads (since the threads will be mostly sleeping, except when waken to draw stuff and sleep again) affect the performance of the user's thread? Would those sleeping threads compromise memory in any significant way?

I've already reiterated over the drawbacks enough times in the last posts and this one. If you still don't understand them, please read them again. I assume that you are somewhat familiar with threading (and more importantly efficient multi-threading), since you often propose "solutions" to problems that involve them in some way. So can't you just draw your own conclusions? If this is not the case, i.e. you are not experienced in threading, then I highly recommend you refrain from using them in any future solutions you propose anywhere. I don't mean to be offensive, but these solutions don't necessarily make you look good...

From what I did understand from your previous posts, the main drawback was that SFML created a lot of useless contexts so that every operation performs on a different context and we don't have to synchronize anything. I might have missunderstood the issues, but my suggestion was made considering this scenario. Please elucidate me if I am mistaken, but after reading the first post of the thread again this is still what I understood.


Ok, so I agree that creating a dedicated thread for each render target and having the context active on that thread might not be a very clean solution. An alternative solution would be to always deactivate contexts after each OpenGL operation, and block threads that want to do OpenGL operations until the previous one stops.
I am not very familiar to C++ mutexes and synchronization, but on Java the code would be something like this for every OpenGL operation:

synchronize (context) {
    // activate context
    // perform OpenGL operation
    // deactivate context
}
 

I assume it would be similar on C++. That way the context will only be active during the operation, and multiple threads trying to use the same context in parallel would be executed one at a time. What I don't know is: does activation and deactivation of contexts take much time, or is it instantaneous? This solution would be bad if activating and deactivating contexts multiple times would lead to performance issues, but if it is as trivial as changing one state, it won't matter much.


Another possible variant of the dedicated internal threads suggestion would be to have only one internal thread, and have it doing the OpenGL operations for all of the contexts. If I understood what you've said on the first post, we might gain some performance if driver operations are issued in parallel to different contexts, so this suggestion would remove this possible performance gain, but you make it sound like driver operations are so fast that the gain is trivial. If that is the case, then this solution will be viable.

18

SFML development / Re: SFML Context Management

« on: October 03, 2014, 07:14:03 am »

Ok, but everything you said just confirmed that my suggestion would be great.

I would like to see a statement by statement reasoning for why you think this. It seems you didn't fully understand what I said.

Ok, I'll quote your post and answer it part by part. I didn't do that before because the topic had too much text for that, and because I wasn't sure how contexts work, even after reading everything. I don't remember ever hearing anything about OpenGL contexts before reading this topic, so I am taking all of my information from here.

Since graphical operations are "returnless", you can just put them on the poll, wake the drawing thread up if it is sleeping and return. It wouldn't have any delay whatsoever for the user's code, and since the operations are going to be done sequentialy anyway, you won't lose any performance (by having only one thread doing all the drawing sequentialy for each render target).

It is ludicrous to think that dedicating another thread just to synchronize access to the driver would help solve this problem. I don't know how much multi-threading you have done, but you do understand that you would have to take care of data synchronization yourself in this case right?

What I understood from previous posts is this: OpenGL uses contexts to manage render targets, and those contexts are not "safe" for multithreading, so they have restricted each context to a single active thread. You can deactivate one thread and activate another, but you can't have two active threads on the same context, so in other words it just forces the user to do the synchronization. My suggestion is that the synchronization is done hidden inside SFML, so that the API can stay the same. The back-end particularities shouldn't have effect on SFML's public API, in my opinion (specially when we consider possible future DirectX support, for example, but lets not diverge from the topic at hand).

Not to mention that there are also functions that don't draw stuff but query the driver for data as well. What would you do in that case? Copy the OpenGL function signatures so you can relay these data structures back and forth as well?

I didn't know we had to synchronize data retrival functions as well. As I've said before, I only know this issue from what I've read here, so if I don't know all of the problems my suggestions will be flawed from the start. How does data retrieval work on OpenGL? Is it thread-safe? Does it support parallel data retrival on multiple threads? Does it use the contexts for that? In what way? I am realy clueless to this point.

What about selecting the right context to draw to in multi-window applications? Would you really have to pass the context to activate along with each function that you call? What benefit does that provide over merely activating the contexts in the main thread and doing all the work there? And the part that I really don't understand is: How would this solve the problem that we are already currently having?

You wouldn't have to pass the context, since the Window object would have its context internaly. The benefit of my suggestion would be that you wouldn't have to worry about the synchronization at all when drawing stuff, the Window's internal thread will do the "talking" with OpenGL and everything will just work. Also, we wouldn't need more contexts than the number of render targets, if my understanding of contexts is correct, but I might be wrong.

You've said that it would be so slow it would cease to be realtime, but why?

You've taken this statement out of context. Please reread that post again if you don't understand.

SFML, and other middleware has done this a lot. They are so desperate to appeal to developers with bad practices or little understanding of the subject matter, that they end up having to hide the real problems from them. Instead of saying "don't worry, you can do what you have always been doing although it is a bad idea" why not say "you know... that is not such a good idea, why not try it like this instead"? Sure some will always complain and threaten to go to another library that keeps pampering them. But trying to keep a hold of those with objectively very very bad practices to the detriment of others willing to improve is not something I feel good about either.

You say that drawing stuff on multiple threads is bad practice, but it is only bad practice if it creates unsolveable issues or if it affects resource usage significantly. Sure, you shouldn't draw from multiple threads on the same context in parallel in OpenGL, but we are talking about SFML, and as long as we can solve OpenGL's issues ourselves without affecting the performance significantly, we can choose our own way of presenting features to the user. In my opinion, the interface should only show an issue to the user if it can't be solved internaly.

I'm not saying that we need to change the way SFML does context management overnight. I'm pretty sure it is possible to keep it the way it is while dealing with some, but not all of the problems that arise. Going out of our way by introducing an additional thread just for rendering, is unheard of, and I've seen a lot over the last years.

Ok, it is unheard of, but would it work? What are the possible drawbacks? Is the number of threads limited to less than the number of possible contexts on an application? Would multiple sleeping threads (since the threads will be mostly sleeping, except when waken to draw stuff and sleep again) affect the performance of the user's thread? Would those sleeping threads compromise memory in any significant way? You have also mentioned data retrieval, and I would like to know how that is done on OpenGL (to try and adapt the "internal thread solution", if it passes the previous questions).

Also, what Ixrec said should be universally true. The amount of effort required to get something done should always be proportional to the complexity of what you want done. Reducing the effort by a flat amount regardless of the complexity leads to situations like the one we have now. If the user wants to multi-thread sfml-graphics, I will tell them that I do not recommend doing it, but it is up to them what their code looks like, and if they are that desperate to do it, they can read a bit more about multi-threaded context management. If you ask me, the effort required to multi-thread properly is much much larger than the effort required to understand how contexts are used in different threads. Most of the time, unfortunately, people fail to do the former already, and we are trying to help hide the latter from them.

So, you are suggesting that since multithreading OpenGL contexts efficiently is hard, you should just force SFML users to do it themselves and give the "OpenGL context" problem to them? I might well be underestimating the problems here (and I probably am), but until I understand the problem I won't assume it is unsolveable, so I am sorry if I am talking nonsense.

19

SFML development / Re: SFML Context Management

« on: October 03, 2014, 03:45:49 am »

Ok, but everything you said just confirmed that my suggestion would be great. Since graphical operations are "returnless", you can just put them on the poll, wake the drawing thread up if it is sleeping and return. It wouldn't have any delay whatsoever for the user's code, and since the operations are going to be done sequentialy anyway, you won't lose any performance (by having only one thread doing all the drawing sequentialy for each render target). You've said that it would be so slow it would cease to be realtime, but why?

20

SFML development / Re: SFML Context Management

« on: October 03, 2014, 02:29:01 am »

Ok, since you seem to know contexts in detail, can you confirm those points for me as well?

• In order to have a render target (Window or RenderTexture, for example) you must have a context bound to that target.
• Every context is bound to a render target, even if to a "virtual" and useless one.
• Each context can only be used by one thread at a time, so you can't use multiple threads to draw to the same render target.

If those points are all true and if I understood the "context leaking" problem right, then the simplest and cleanest way to solve those problems would be to have an internal SFML graphical thread (like the internal audio thread) for each render target, and all drawing operations on said render targets would be performed by that thread. You can have a poll of drawing operations for the render target and have that thread go over it whenever a new operation pops up.

You said it yourself that multithreading is useless to gain performance on the context operations, so this would keep contexts hidden and only create contexts when neccessary. That is, assuming I understood these contexts right. If the drawing operations have useful returning values, it is always possible to block the calling thread untill the drawing thread finishes the task, and get the result back afterwards.

21

SFML development / Re: SFML Context Management

« on: October 02, 2014, 05:18:58 am »

From what I could understand from your post, apart from that "context leak" issue, I see no reason at all to even consider those contexts. Maybe SFML's internal code could be improved to remove those useless contexts as you've said, but why would I want to manually use them? What could I do with direct access to them that I can't do now?

Aside from that, what about DirectX rendering support? If it is implemented (and I hope it gets into SFML3), won't contexts only exist natively on OpenGL supported devices? In my oppinion, DirectX support is much more appealing to me than those contexts (I might change my mind depending on your answers to my previous paragraph, but I find it unlikely).

22

General discussions / Re: Replacement for OpenAL

« on: September 26, 2014, 09:34:57 am »

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

Ok, thank you!

I've stumbled upon http://www.xiph.org/downloads/, and there are a lot of libraries there for different audio formats. I believe you are using those libs, right? There is one for FLAC as well.

23

General discussions / Re: Replacement for OpenAL

« on: September 26, 2014, 09:00:04 am »

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, the plan appears to be using libraries like libogg and libvorbis.

Interesting. What about WAV support? Can libogg parse WAV files as well?

24

General discussions / Re: Replacement for OpenAL

« on: September 26, 2014, 07:03:01 am »

Ok, I think I've managed to strip all of JUCE's code out of my local version of the library and replace most of it's functionality by C++11 equivalent functions. The platform interaction was already coded for DirectSound on that fork I mentioned earlier, so in order to produce a test version of YSE without JUCE I just need some library that can parse audio files. Those two were all of the features from JUCE that weren't readily replaceable by C++11 code, as far as I could see.

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?

25

SFML projects / Re: Rage - a "modern" rogue-like

« on: September 24, 2014, 09:38:10 am »

If all you want to have is circular visibility, you can always make an image with a transparent circle in the middle, semi-transparent black color everywhere else, then draw that on top of everything. What is outside the circle should get darker. You can even get gradient shadows with that trick.

26

General discussions / Re: Do you use radians or degrees?

« on: September 21, 2014, 10:38:46 pm »

The content code for my engine always uses angles as degrees. I think some time or another I have to use radians on my engine's internal code to compute some geometric stuff, but never on content code. Degrees are just easier to understand and to deal with, even though radians are a little easier to use on computations.

27

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 10:17:23 pm »

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

I'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.

Sure, but then the library would still be under LGPL.

would have YSE ready for using any of its other functions

Not through SFML, then?

Yes, or at least until SFML implements them.

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.

JUCE 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.
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?

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.

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.

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.

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.

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

To sum it up for anyone arriving here now: I am not asking for anyone to do anything anymore. I am going to at least try to get YSE to work with its Eclipse license and wrap it on an OpenAL API myself, so that I can replace the current OpenAL implementation with it. No point arguing about the same points again, so please read all previous messages before posting, and lets just stop talking about asset leaking and focus on useful discussion about the work I am trying to do. All this arguing is not geting us anywhere.

28

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 10:27:29 am »

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?

29

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 08:26:05 am »

ease of porting for platforms without OpenAL

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

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.

music synthesis and MIDI reproduction

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

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.

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.

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.

For me it is worth spending some time to get what I am after on the audio department

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

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.

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.

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

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.

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.

P.S.: If all the LGPL license cares about is that you share your modifications with the community, there would be no need to prevent static linking. You could still staticaly link the modified library and share it's code. They enforce dynamic linking so that any software that uses the library can be "injected" with any modified version of the library, and that is just wrong, in my opinion.

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.

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.

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

Code: [Select]

...

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.

30

General discussions / Re: Replacement for OpenAL

« on: September 21, 2014, 02:23:06 am »

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.

Anyway, lets please stop talking about resource leaking and modifications to SFML for a while. 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.

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