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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dk123

Pages: 1 2 3 [4]
46
E-mail from Erik, 8 months ago:

Quote
Hi Laurent,

Dealing with this issue is high on my todo list.

I intend to email all the people who have significant contributions
to libsndfile and ask them if they are OK with a modification to
libsndfile's license.

That modification would be to change libsndfile to LGPL with a
static linking exception on iOS and any other OS which does not
provide support for dynamic linking.

This change keeps the spirit of the LGPL and fixes the issue with
iOS.

Cheers,
Erik

Nothing else since then.

libsndfile is not an audio player. It's just an audio file reader/writer. And no other library does that.

If I redesigned the audio module so that it is more abstract, I could plug other file backends, and easily provide support for at least OGG, WAV and Apple's audio format(s) on iOS.

Thanks for quoting the email, it's good to see the reply.

This is just my person opinion, but if libsndfile's license change is something that still doesn't have an estimated date, it might be more worthwhile to, as you've said, first redesign the audio module to allow users to play at least OGG, WAV, and Apple's audio format(s) on iOS.

I feel users' first priority is in actually getting audio to play - most games are nothing without sound, and if the price to pay is some abstraction, I feel that most would comply than go without an entire audio module which in many cases prevents development completely.

If some time afterwards libsndfile does make the license change, then we could perhaps revert back to the original code at that point and remove the abstraction layer.

All in all, I feel this is more a time issue - if libsndfile's license change is unpredictable then I sense that abstracting the audio module to provide users with basic sound play, and reverting the code after libsndfile's license change (whenever that may be) may be a more attractive stance to take.

It may perhaps be worthwhile to send Erik another email to ask if there's been process over the last 8 months.



47
General discussions / Re: SFML 3 - What is your vision?
« on: May 06, 2014, 04:06:18 pm »
I added a few opinions in a previous post, but I'd like to also add one thing:

- movie playback (desktop + android/ios)

With narrative becoming a key part in modern day games, movie insertion in games are becoming more and more an important element. It would be great if SFML could get this internally done and also on mobile platforms for SFML 3.

48
I just want to ask about the feasibility of waiting for libsndfile license changes for iOS.

I remember someone mentioning this in a previous post, but here's the post 2 years ago from Stack Overflow where the person who calls himself the main maintainer of libsndfile states:

Quote
Unfortunately libsndfile has lots of copyright holders and I simply don't have the patience to track them all down and ask them if its ok

https://stackoverflow.com/questions/4939268/can-the-libsndfile-library-be-used-on-the-iphone-ios

I'm just wondering if looking into other c++ audio libraries may be more practical.
Here's one I've found while googling that seems to support OSX and iOS (I'm sure there are also others):

https://github.com/sbooth/SFBAudioEngine


49
General discussions / Re: SFML 3 - What is your vision?
« on: April 30, 2014, 04:47:35 pm »
- c++11 addition
- more text flexibility
- emscripten

I just want to point out if someone can get a emscripten backend in place, then people can wrap things in Phonegap or Crosswalk and also get things running on mobile.

As for flexibility with text:
- Ability to define colours within the text
- Ability to change size within the text
- Ability to change style within the text (bold/italic,etc)
- Automatic changing of line when text passes a certain width
- Vertical text output

These are the features that initially come to mind. Changing colours/size/style of parts within text can currently only be done by chopping strings up, applying the styles, and sticking them together in appropriate screen locations.

It would be great if SFML could do these internally without any external fuss.

Anyway, it's great that people are discussing about the future.
Good to see all the conversations freely going about.

Pages: 1 2 3 [4]