SFML community forums
General => Feature requests => Topic started by: amir ramezani on April 23, 2015, 06:17:41 pm
-
hi all
as the topic subject says, i recommend to use OpenSLES instead of OpenAL witch is a GPL license and requires a game to have a DLL or a Shared library beside it.
OpenSLES is tiny, just 14 KB with a 1 c Source file and 2 Headers witch you just include OpenSLES.h and use it!
it supports 3D, can run in Windows, linux, mac, android and any mobile device, and it Supports midi
after i saw that, i have been surprised!
it is a cool library!, and it is not GPL based that means no Shared library anymore!
-
I don't know the lib (but will check it out). But I'm wondering why having to ship a dll or two is such a big deal?
Most games will have to ship lots of files anyway; like resources, config files etc. Why's an extra shared library or two such a big deal??
-
You aren't the first one who thought of OpenSL ES. I've already done my research in the past on the plethora of Khronos APIs besides OpenGL which we already use.
The main problem is that Khronos only provides the specification of the APIs. Others have to become interested and ultimately implement them in some form, on all the platforms that they intend on supporting. This is already the case with OpenGL. AMD/Nvidia/Mesa provide the implementations on all the platforms that SFML supports. OpenGL ES is only really supported on the mobile platforms and by Mesa on Linux, so no OpenGL ES on Windows which means we can't move to OpenGL ES yet.
OpenSL ES is "even worse" in that respect. It is an API specification just like everything else, but until now I haven't found an implementation of it for any desktop platform, so SFML won't be using it any time soon. If you ask me, Vulkan will see more cross-platform support within weeks of its public release than OpenSL ES will do in the coming years.
Please do a bit more research next time. Uploading an archive containing just the API headers is barely anything, and nothing SFML can make use of.
-
i'm not saying that a shared library is a problematic thing
but, i said to avoid using GPL licenses, and this is not a GPL specification
as i said, it can easily be embedded into any device witch needs sound support
-
Personally I quite like the (L)GPL licenses. They ensure that when I give away code freely I'll get changes/improvements back and noone can take my code proprietary without my permission. You can still use the code in proprietary apps though, as long as you share your modifications to the (L)GPL bits and allow users to relink against newer versions etc etc. I see this as a good thing, not something to avoid.
But that's just my opinion.
-
but, i said to avoid using GPL licenses, and this is not a GPL specification
Did you even read what I posted? What you said doesn't make sense. OpenSL ES is a specification as you said. Specifications are not covered by GPL, so there is no such thing as a GPL specification. What you still don't seem to understand is that the implementation, if one is ever available for desktop platforms, can be licensed under the GPL.
Please understand the difference between a specification and an implementation before making any further points.
as i said, it can easily be embedded into any device witch needs sound support
Have you actually tried to use "it" yet? What you provided is non-functional, like I've said repeatedly, it is missing an implementation and thus there is nothing to embed into any device. It's like us giving you the SFML header files and claiming you can embed SFML into any device just using those, without the need for the actual implementation code. If you don't understand this, read it multiple times. If you still don't understand it then I really recommend learning about the difference between a header file and a source file.
-
They ensure that when I give away code freely I'll get changes/improvements back
There are other licenses that ensure that in less troublesome ways.
noone can take my code proprietary without my permission.
There are other licenses that ensure that in less troublesome ways (and why would you want that really...?).
You can still use the code in proprietary apps though, as long as you share your modifications to the (L)GPL bits and allow users to relink against newer versions etc etc.
You can't do linking thing with GPL, only LGPL. And you can't dynamically link on iOS at all. And GPL and LGPL v3 are also by design incompatible with iOS and other tightly closed platforms (and with v2).
no OpenGL ES on Windows which means we can't move to OpenGL ES yet.
What about using angle for that...?
-
They ensure that when I give away code freely I'll get changes/improvements back
There are other licenses that ensure that in less troublesome ways.
Less troublesome for whom?
I personally like the freedoms and guarantees that the GPL gives me as a deceloper. If that's more trouble for others I don't care; if they don't like the license they can just write their own code (like they always could).
noone can take my code proprietary without my permission.
There are other licenses that ensure that in less troublesome ways (and why would you want that really...?).
I'd want that if I wanted to ensure my code was only ever used in a free manner and never in a proprietary one. And yes, that's something that I might want.
You can still use the code in proprietary apps though, as long as you share your modifications to the (L)GPL bits and allow users to relink against newer versions etc etc.
You can't do linking thing with GPL, only LGPL.
There are still ways to use gpl code in commercial apps. It's being done daily...
And you can't dynamically link on iOS at all. And GPL and LGPL v3 are also by design incompatible with iOS and other tightly closed platforms (and with v2).
Personally, that suits me just fine. Don't want to support that company and their platforms. They can write their own code; not reuse mine. Works out just fine.
-
Please discuss your favorite license somewhere else. We've already had enough of these unproductive discussions.
-
Ok. Fair enough. I'll shut up now.
-
but, i said to avoid using GPL licenses, and this is not a GPL specification
Did you even read what I posted? What you said doesn't make sense. OpenSL ES is a specification as you said. Specifications are not covered by GPL, so there is no such thing as a GPL specification. What you still don't seem to understand is that the implementation, if one is ever available for desktop platforms, can be licensed under the GPL.
Please understand the difference between a specification and an implementation before making any further points.
as i said, it can easily be embedded into any device witch needs sound support
Have you actually tried to use "it" yet? What you provided is non-functional, like I've said repeatedly, it is missing an implementation and thus there is nothing to embed into any device. It's like us giving you the SFML header files and claiming you can embed SFML into any device just using those, without the need for the actual implementation code. If you don't understand this, read it multiple times. If you still don't understand it then I really recommend learning about the difference between a header file and a source file.
i know the differences between a header and a implementation!
like VST 2.x that is header-only, you can write your plugins or a VST host!, this is a standard.
for implementation, anybody can write there own code and with a specification, it must not be hard
the interface codes are declared, so you dont need to worry about it.
my mean is not to totaly avoid using GPL licenses, but they are very restricted.
-
I think there is still some confusion. Your original feature request was to switch over to using OpenSL ES. What binary1248 is trying to say is that would be impossible to do because there is no implementation of OpenSL ES. Sure, using the header you could write code that makes use of OpenSL ES, but then you have nothing to link against and it won't run on any platform. That would basically mean SFML would be broken for everyone until someone made a library that implements OpenSL ES.
I'm not familiar with OpenSL ES myself. This is just what I have gathered from the discussion here.
-
There's already a OpenAL backend that uses SL ES, that's how sfml audio runs on android I believe
-
There's already a OpenAL backend that uses SL ES, that's how sfml audio runs on android I believe
Yes, although the Android implementation isn't 100% compliant either, to quote (http://mobilepearls.com/labs/native-android-api/ndk/docs/opensles/):
Note: though based on OpenSL ES, the Android native audio API is not a conforming implementation of any OpenSL ES 1.0.1 profile (game, music, or phone). This is because Android does not implement all of the features required by any one of the profiles. Any known cases where Android behaves differently than the specification are described in section "Android extensions" below.