Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: use OpenSLES instead of OpenAL  (Read 12255 times)

0 Members and 1 Guest are viewing this topic.

amir ramezani

  • Jr. Member
  • **
  • Posts: 81
  • i'm a programmer who can't see well
    • View Profile
    • download useful software!
    • Email
use OpenSLES instead of OpenAL
« 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!
if you can't see well, you can't test your applications and operating system well
my game engine:
allegro game creator
my operating system:
AmirOS

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #1 on: April 23, 2015, 06:23:36 pm »
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??

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: use OpenSLES instead of OpenAL
« Reply #2 on: April 23, 2015, 06:46:15 pm »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

amir ramezani

  • Jr. Member
  • **
  • Posts: 81
  • i'm a programmer who can't see well
    • View Profile
    • download useful software!
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #3 on: April 23, 2015, 09:51:11 pm »
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
if you can't see well, you can't test your applications and operating system well
my game engine:
allegro game creator
my operating system:
AmirOS

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #4 on: April 23, 2015, 09:58:52 pm »
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.

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: use OpenSLES instead of OpenAL
« Reply #5 on: April 23, 2015, 10:01:11 pm »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #6 on: April 23, 2015, 10:40:32 pm »
Quote
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.

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

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

Quote
no OpenGL ES on Windows which means we can't move to OpenGL ES yet.
What about using angle for that...?
« Last Edit: April 23, 2015, 10:42:06 pm by FRex »
Back to C++ gamedev with SFML in May 2023

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #7 on: April 23, 2015, 10:58:17 pm »
Quote
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).

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

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

« Last Edit: April 23, 2015, 11:04:18 pm by Jesper Juhl »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10801
    • View Profile
    • development blog
    • Email
AW: use OpenSLES instead of OpenAL
« Reply #8 on: April 23, 2015, 11:04:05 pm »
Please discuss your favorite license somewhere else. We've already had enough of these unproductive discussions.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #9 on: April 23, 2015, 11:05:26 pm »
Ok. Fair enough. I'll shut up now.

amir ramezani

  • Jr. Member
  • **
  • Posts: 81
  • i'm a programmer who can't see well
    • View Profile
    • download useful software!
    • Email
Re: use OpenSLES instead of OpenAL
« Reply #10 on: April 24, 2015, 09:09:44 am »
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.
if you can't see well, you can't test your applications and operating system well
my game engine:
allegro game creator
my operating system:
AmirOS

Arcade

  • Full Member
  • ***
  • Posts: 230
    • View Profile
Re: use OpenSLES instead of OpenAL
« Reply #11 on: April 24, 2015, 04:45:02 pm »
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.

Grimshaw

  • Hero Member
  • *****
  • Posts: 631
  • Nephilim SDK
    • View Profile
Re: use OpenSLES instead of OpenAL
« Reply #12 on: April 29, 2015, 01:18:28 am »
There's already a OpenAL backend that uses SL ES, that's how sfml audio runs on android I believe

Mario

  • SFML Team
  • Hero Member
  • *****
  • Posts: 879
    • View Profile
Re: use OpenSLES instead of OpenAL
« Reply #13 on: May 18, 2015, 02:04:59 pm »
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:

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

 

anything