SFML community forums

General => General discussions => Topic started by: Triebr on April 30, 2013, 05:13:40 am

Title: Android/iOS "Soon"
Post by: Triebr on April 30, 2013, 05:13:40 am
I noticed the main page of SFML says Android and iOS will be supported "Soon", but looking through the source I don't see any mention of Android or iOS.

How "soon" is soon? Has any work been started on these ports?

I currently use SDL2 which is easy to use on Android/iOS but SDL2 is still unstable, and I prefer SFML because it is C++ so I am interested to see an estimate on when Android support will be available.
Title: Re: Android/iOS "Soon"
Post by: Jebbs on April 30, 2013, 05:27:14 am
Well, considering how long it took SFML 2.0 to come out you'll probably be waiting a while :P

But in all seriousness....

Some news for the near future:
- SFML 2.1 will be released as quickly as possible and be a bug fix release
- SFML 2.2 should add support for iOS, I'm already working on it

This is a pretty big project. All of the OpenGL code used needs to be done with OpenGL ES code. I don't know much about either Android or iOS development so there may be some other specific tweaks to get it to work in those systems as well. Basically a lot of updates and testing. It's probably going to be a while.
Title: Re: Android/iOS "Soon"
Post by: Laurent on April 30, 2013, 08:46:31 am
I already started to work on the iOS port, but I'm going to stop and focus on fixing bugs for SFML 2.1. Android will come later, I don't know when. I still haven't started to investigate how Android and the NDK work.

However there are already users working on unofficial Android ports (see this pos (http://en.sfml-dev.org/forums/index.php?topic=11299.msg78391#msg78391)t for example). I'm sure there will be more of them in the near future.
Title: Re: Android/iOS "Soon"
Post by: game_maker on August 02, 2013, 12:35:48 am
Will the bindings support iOS and Android? Which ones?
Title: Re: Android/iOS "Soon"
Post by: Jebbs on August 02, 2013, 03:50:37 am
Will the bindings support iOS and Android? Which ones?

The .Net and C bindings are the only ones Laurent actually provides. I can't say for sure about the .Net ones, but the C bindings should support both once SFML itself does. Everything else is dependent on if the language the binding is for runs on iOS/Android systems and if the developers of the bindings can get everything working.
Title: Re: Android/iOS "Soon"
Post by: Laurent on August 02, 2013, 07:40:17 am
There should be no problem for CSFML. I don't know for other languages, I haven't investigated yet.
Title: Re: Android/iOS "Soon"
Post by: game_maker on August 03, 2013, 12:56:36 am
It's awesome.

Thank you!
Title: Re: Android/iOS "Soon"
Post by: cpolymeris on August 05, 2013, 09:02:53 am
All of the OpenGL code used needs to be done with OpenGL ES code.

Slightly offtopic, but that would open the door to an SFML port to the Web/EGL. Interesting...
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on August 07, 2013, 10:48:10 pm
Just a little Feedback to the esfml-port running under Ubuntu (AC100 withTegra2):

I get a undefined Reference error on GlxContext::selectBestVisual(...) in WindowImplX11.cpp

This is obvious since there is no GlxContext on SFML_EMBEDDED_SYSTEM but EGLContext, which is missing this function.

My workaround so far is to change WindowsImplX11.cpp (Step 1) to:

#ifndef SFML_EMBEDDED_SYSTEM
    visualInfo = GlxContext::selectBestVisual(m_display, mode.bitsPerPixel, settings);
#else
    visualInfo = _EGLContext::selectBestVisual(m_display, mode.bitsPerPixel, settings);
#endif

Step 2 is to implement selectBestVisual in EGLContext but i only return the first visual instead of calculating the best one. I couldn't figure it out for EGL :-(.

I guess this is no problem for Android since it does not use X11.
Title: Re: Android/iOS "Soon"
Post by: Sonkun on August 08, 2013, 12:27:55 am
Thanks for your feedback.

Maybe I messed up a commit last time I had to rebase eSFML on SFML 2.1. I assume I'll get the same behavior tomorrow on my Raspberry Pi if your laptob is ARM-based.
Title: Re: Android/iOS "Soon"
Post by: Sonkun on August 09, 2013, 12:56:09 am
I couldn't reproduce your compilation error on my Raspberry Pi with Pidora as OS. However I noticed other errors which are now fixed. What branch are you compiling ? The master or the Android branch ? Both should work though.

This is weird. I couldn't figure out why you're having this error. I mean, I glanced the code and it's obvious a method definition is missing but why am I not getting it on my Raspberry Pi which does compile WindowImplX11.cpp but doesn't compile GlxContext.cpp which is correct.

Just like that, try a verbose make (make VERBOSE=1) and verify if -DSFML_EMBEDDED_SYSTEM is sent. I'm wondering if CMake thinks, as you're on Ubuntu, you're not on an ARM based system (and so doesn't set SFML_EMBEDDED_SYSTEM variable to True).
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on August 09, 2013, 05:27:18 pm
I used the master-branch in my test (downloaded as ZIP from github).

Now I cloned the master and tried again, same error.


Just to be clear: I can compile the esfml-Projekt using cmake and make, but I cant complie my project using libsfml, throwing:
/usr/local/lib/libsfml-window.so:-1: error: undefined reference to `sf::priv::GlxContext::selectBestVisual(_XDisplay*, unsigned int, sf::ContextSettings const&)'



Minimal example:
#include <sfml/graphics.hpp>
int main()
{
    sf::RenderWindow win(sf::VideoMode::getDesktopMode(),"test");
    return 0;
}

 

Compiling with:
g++ -o test main.cpp -lsfml-graphics -lsfml-window -lsfml-system -lEGL -lGLESv1_CM

btw: Is there a reason why you changed the Include-Files from UpperCase to LowerCase?
include/SFML/Graphics.hpp
to
include/sfml/graphics.hpp
Title: Re: Android/iOS "Soon"
Post by: Sonkun on August 09, 2013, 07:52:28 pm
-DSFML_EMBEDDED_SYSTEM is missing. That means CMake failed to detect your platform and thus, has set SFML_EMBEDDED_SYSTEM at false. Try:

cmake -DSFML_EMBEDDED_SYSTEM


btw: Is there a reason why you changed the Include-Files from UpperCase to LowerCase?
include/SFML/Graphics.hpp
to
include/sfml/graphics.hpp
This is an experimental repository meant to try new stuff. The Android port was a new stuff and it will be adapted then merged into the official repository soon. You can read the wiki.
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on August 09, 2013, 08:19:19 pm
Damn, somehow I removed this from my last post:

Flags from make VERBOSE=1 for sfml-graphics:

-DGLEW_STATIC -DGL_GLEXT_PROTOTYPES -DSFML_EMBEDDED_SYSTEM -DSFML_GRAPHICS_EXPORTS -DSTBI_FAILURE_USERMSG -O3 -DNDEBUG -fPIC


So -DSFML_EMBEDDED_SYSTEM is not missing.

Nevertheless I try again with
Code: [Select]
cmake -DSFML_EMBEDDED_SYSTEM=1 ..
make
sudo make install

But compiling of the minimal example still causes the same error.

#include <sfml/graphics.hpp>
int main()
{
    sf::RenderWindow win(sf::VideoMode::getDesktopMode(),"test");
    return 0;
}
 

Code: [Select]
g++ -o test main.cpp -lsfml-graphics -lsfml-window -lsfml-system -lEGL -lGLESv1_CM
Code: [Select]
/usr/local/lib/libsfml-window.so: undefined reference to `sf::priv::GlxContext::selectBestVisual(_XDisplay*, unsigned int, sf::ContextSettings const&)'


Does the example compile on your RPi?
Title: Re: Android/iOS "Soon"
Post by: Sonkun on August 09, 2013, 10:43:22 pm
Fuck >.< I forgot undefined references only show up when you compile a project using the libraries. Well, I'm getting the same errors then. It seems I broke something during my last rebase because I remember I had the examples compiling and running well. I can't find _EGLContext::selectBestVisual() neither, strange. I'll figure that out tomorrow and give you news as soon as it's fixed. Thank you.
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on August 14, 2013, 11:36:05 am
GlxContext::selectBestVisual() was added by Laurent when commiting "Fixed ContextSettings ignored on Linux when creating a window (#35)" 24 days ago.

As far as I can see, GlxContext was not used in WindowsImplX11.cpp before, so EglContext didn't have to be included neither.
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 09, 2013, 12:10:38 am
Any chance we could get an update on how the Android/iOS ports are going?
Title: Re: Android/iOS "Soon"
Post by: iroquai_tribe on October 09, 2013, 12:51:11 am
This is my first post so, first of all, I would like to congratulate everybody on the SFML team.
I've been using SFML for a while so I think it's time to participate in the forums and join this awesome comunity.

I've downloaded Sonkun's eSFML and tried to make it work in a raspberry pie without success. I stumbled in the same problem as Ghosa: the undefined reference to
sf::priv::GlxContext::selectBestVisual(_Xdisplay*, unsigned int, sf::ContextSettings const&);

I digged a little bit and found that the _EGLContext class is missing this method. Should it be declared in the GlContext class and then defined in the _EGLContext class (I'm no expert at all in this... just trying to guess  :P)

Is there any way to fix this? As described by Ghosa this happens when linking with the -lsfml-window flag.

Thanks  :)
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on October 09, 2013, 11:28:03 am
Best way would bei to Include EGLContext in WindowsImplX11.cpp
and to add the Method "selectBestVisual"

The Problem is that you can't calculate the BestVisual with EGL in the same way as GLX.

But for a quick fix you can just return the first XVisualInfo.
Worked for me, but you might noch get Antialiasing.
Title: Re: Android/iOS "Soon"
Post by: Laurent on October 09, 2013, 11:42:02 am
Android and iOS ports are implemented. Now we are busy adjusting some details and fixing a few things that don't work as expected.

I don't think Jonathan still maintains the eSFML repository, you should rather wait for the new code to be available. We'll try to push it to the public repository before the end of the month if possible.
Title: Re: Android/iOS "Soon"
Post by: iroquai_tribe on October 09, 2013, 01:05:52 pm
Hi!

We'll try to push it to the public repository before the end of the month if possible.
That's great news! I'm eager to see the performance of the raspberry using SFML. I think both the Android and the iOS ports will be a major addon to the library and open the door to many other developers who use those platforms.

But for a quick fix you can just return the first XVisualInfo.
Worked for me, but you might noch get Antialiasing.
Meanwhile, I'm going to try Ghosa's sugestion just to get things going :)

Thank you both!
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on October 09, 2013, 01:32:16 pm
Yeah, great news :-).

@ iroquai_tribe
If you want it, i could give you my fix when I get home.
Title: Re: Android/iOS "Soon"
Post by: iroquai_tribe on October 09, 2013, 03:16:46 pm
If you want it, i could give you my fix when I get home.

That would be awesome, thanks :)
Title: Re: Android/iOS "Soon"
Post by: eigenbom on October 10, 2013, 01:12:34 am
Android and iOS ports are implemented. Now we are busy adjusting some details and fixing a few things that don't work as expected.

That's really excellent news, congrats! I'm really looking forward to deploying SFML hello world on my ipad! :)
Title: Re: Android/iOS "Soon"
Post by: G. on October 10, 2013, 04:04:49 am
Next step: WebGL? :p
Title: Re: Android/iOS "Soon"
Post by: Rhimlock on October 10, 2013, 09:29:34 am
That would be awesome, thanks :)

OK, here is the quick an dirty fix to make the ESFML-Code on Github run with EGL under Linux.
I don't have my AC100 here to test it, so I hope I didn't forget anything:

WindowImplX11.cpp
Change Line 31:
#include <sfml/window/Linux/GlxContext.hpp>
to:
#ifndef SFML_EMBEDDED_SYSTEM
        #include <sfml/window/Linux/GlxContext.hpp>
    #else
        #include <sfml/window/Linux/EGLContext.hpp>
    #endif


Change Line 152:
XVisualInfo visualInfo = GlxContext::selectBestVisual(m_display, mode.bitsPerPixel, settings);

to:
#ifndef SFML_EMBEDDED_SYSTEM
        XVisualInfo visualInfo = GlxContext::selectBestVisual(m_display, mode.bitsPerPixel, settings);
    #else
        XVisualInfo visualInfo = _EGLContext::selectBestVisual(m_display, mode.bitsPerPixel, settings);
    #endif


EGLContext.hpp

Add:
    static XVisualInfo selectBestVisual(::Display* display, unsigned int bitsPerPixel, const ContextSettings& settings);


EGLContext.cpp

Add:
XVisualInfo _EGLContext::selectBestVisual(::Display* display, unsigned int bitsPerPixel, const ContextSettings& settings)
{
    // Retrieve all the visuals
    int count;
    XVisualInfo* visuals = XGetVisualInfo(display, 0, NULL, &count);
    if (visuals)
    {

        XVisualInfo bestVisual;
        //ToDo: Calculate best Visual        
        //select first Visual for now
        bestVisual = visuals[0];
        return bestVisual;
    }
    else
    {
        // Should never happen...
        err() << "No EGL visual found. You should check your graphics driver" << std::endl;

        return XVisualInfo();
    }
}
Title: Re: Android/iOS "Soon"
Post by: iroquai_tribe on October 11, 2013, 01:43:32 am
Thanks for the code! I think I tried something like that to fix the problem but I was having some problem with the "XVisualInfo" not being defined in EGLContext. If I recall correctly it is defined in the glext.h header file which is only included in the GlxContext. I'm not sure though... I'll definitely take a look at that this weekend.

Thanks  :)
Title: Re: Android/iOS "Soon"
Post by: game_maker on October 13, 2013, 12:22:04 am
Excellent news. Thanks SFML-Team for your great job.
Title: Re: Android/iOS "Soon"
Post by: Pippers on October 13, 2013, 01:12:52 am
How does something like SFML become available for IOS exactly? I've never done any IOS programming, but looking over it, it looks like it uses Objective C, which on a quick glance looks entirely different than C++. It also seems to use its own libraries and emulators to dump out the IOS executable. Is SFML just being ported to Obj C and will be a simple add-on into XCode or something? How cross platform compatible would the code even be for current projects?

Just trying to wrap my head around how that entire process works.
Title: Re: Android/iOS "Soon"
Post by: Laurent on October 13, 2013, 08:55:19 am
It's not different than OS X, i.e. you can mix C++ and Objective-C in an iOS app. So this won't change anything for the end user, one can directly compile his C++ SFML application on iOS and Android and it will run fine.
Title: Re: Android/iOS "Soon"
Post by: jagt on October 20, 2013, 06:02:06 pm
Hi.

Really excited about the upcoming iOS/Android release. Now we can have a C++ game library on mobile platform with sane API :)

I'm wondering if audio will be support on iOS, since the libsndfile is LGPL. I've seen a post earlier says that it might be missing. What's the current situation?

Another thing is that will sfml ui be ported too?

Thanks!
Title: Re: Android/iOS "Soon"
Post by: zsbzsb on October 20, 2013, 06:17:30 pm
Another thing is that will sfml ui be ported too?

You mean like TGUI and SFGUI? Well they are not official libraries, so it would be up to the authors of those libraries.
Title: Re: Android/iOS "Soon"
Post by: Laurent on October 20, 2013, 06:32:55 pm
After I wrote to the author of libsndfile he said that he would contact all the copyright holders (there seems to be a lot), and make a license exception that would allow static linking on iOS. I'm still waiting for news, so at the moment there's no audio on iOS.
Title: Re: Android/iOS "Soon"
Post by: FRex on October 20, 2013, 06:39:41 pm
What about OpenAL, doesn't Apple's core audio provide same API or is it missing too because soft is LGPL?
Title: Re: Android/iOS "Soon"
Post by: Laurent on October 20, 2013, 07:35:15 pm
Apple provides its own implementation of OpenAL for iOS.
Title: Re: Android/iOS "Soon"
Post by: wintertime on October 20, 2013, 08:06:21 pm
As you are talking already about those LGPL libraries and the licensing complications here; I read the LGPL, but didn't really understand all the legalese, still I guess one would have to include a file with the text of the license and also source code of these libraries. I didn't see these things in the SFML github although the dll files are in there which confuses me?
Title: Re: Android/iOS "Soon"
Post by: FRex on October 20, 2013, 08:19:12 pm
Apple provides its own implementation of OpenAL for iOS.
I know/had vague idea they do. ;) So just file loading is missing.. that's awkward.. :-X
Title: AW: Re: Android/iOS "Soon"
Post by: eXpl0it3r on October 20, 2013, 10:00:27 pm
still I guess one would have to include a file with the text of the license and also source code of these libraries. I didn't see these things in the SFML github although the dll files are in there which confuses me?
Not sure if you have to include the fulll license file, but the various licenses are mentioned in SFML's license.txt (https://github.com/SFML/SFML/blob/master/license.txt).
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 20, 2013, 11:28:10 pm
As you are talking already about those LGPL libraries and the licensing complications here; I read the LGPL, but didn't really understand all the legalese, still I guess one would have to include a file with the text of the license and also source code of these libraries. I didn't see these things in the SFML github although the dll files are in there which confuses me?

I spent a stupid amount of time reading up on all the details of the GPL and LGPL so I can probably answer some of this stuff.

Technically, I think SFML is supposed to include a full copy of the LGPL text in its distribution (LGPL (https://www.gnu.org/licenses/lgpl.txt) section 4b, rationale explained here (https://www.gnu.org/licenses/gpl-faq.html#WhyMustIInclude)), but that's the only requirement it might be missing.  The main point of the LGPL is ensuring that anyone who uses the software is free to replace the LGPL'd library with a modified version if they so choose.  This usually means either providing source code for the whole program, object files for the whole program, or dynamically linking the library.  You don't need to do more than one of those.  People usually pick dynamic linking for LGPL libraries because that's much easier than providing source code or object files for the whole program; if anyone wants the library's source code you can just point them to the library's own page.

With GPL things are much simpler because any program using any GPL'd code must itself be under the GPL.  An LGPL'd library can be use without putting your whole program under LGPL, as long as you do dynamic linking or one of the other options.  Of course, a lot of us don't want those restrictions.  A library designed for making 2D games that didn't allow you to sell* the games you made with it would be rather strange.

*Technically you can sell (L)GPL'd code, but all buyers have the legal right to redistribute it for free if they want, so it kinda doesn't count.
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 12:15:52 am
Quote
*Technically you can sell (L)GPL'd code, but all buyers have the legal right to redistribute it for free if they want, so it kinda doesn't count.
There are (very very few) GPL games that sell 'content' not code. And without scripts, textures, configs, maps, images, music and what not the thing might be useless so. ;D

Quote
dynamically linking the library
That's apparently(?) a problem for iOS apps, maybe Hiura will know. iOS is closed as hell, even App Guidelines on their page requires sign in(=99$/year for being in their developer program).
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 21, 2013, 12:28:13 am
Quote
*Technically you can sell (L)GPL'd code, but all buyers have the legal right to redistribute it for free if they want, so it kinda doesn't count.
There are (very very few) GPL games that sell 'content' not code. And without scripts, textures, configs, maps, images, music and what not the thing might be useless so. ;D

Yeah, it's pretty clear that those things count as "data" and thus the GPL doesn't apply to them, but then you need to distribute them with the GPL code to have a complete game, so you need to keep the source code for that publicly available somewhere, with clear version labels so everyone can get the one matching their version of the game...it quickly turns into the kind of thing no one should have to think about when developing a game.  You should publish source code because you feel like it, not because your libraries force you to.

Since SFML uses zlib/png, none of us ever have to think about this stuff, much less make complicated ideological decisions about whether our software or parts thereof should be "free as in speech"/copyleft'd, or major design decisions based largely on circumventing license restrictions we don't want "infecting" our program, and so on.  And I greatly appreciate that Laurent and the sndfile guys are going to the trouble of trying to make it this nice and simple with the iOS port too.  Thank you!
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 01:05:43 am
The problem is GPL(and by extension BSD and zlib style licenses) might end up being hated by devs/corps/whoever because it cock blocks a platform to ensure freedom of users that already chose a walled garden and do not give remote shit about privacy, freedom or what language, tech, OS or license their software is in...

Also no-one-tells-me-what-to-do attitude comes into play, that's one of reasons I dislike GPL. If I got good money out of SFML powered stuff I'd probably donate to it(and to other libraries I use too, of course) a tiny bit of my profit and open the code a while later to help others(and of course, in turn, make SFML better, more popular and make my experience with it more marketable and profitable, after all, most of these profits would go to me, I'm not charity), but just because I want to give something back and not feel like a leech, not because I was forced to by annoying license that protects freedom of users that don't give a shit anyway.

But if forced to by something superior(ie. id tech games that use it for free) or by own choice(ie. Frogatto) GPL for games makes sense, no pirate is going to compile your game and pirate assets, they will just pirate (cracked) exe and content together and never look at the code just like they would with a closed source game.
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 21, 2013, 01:08:51 am
How do BSD and zlib do that?  LGPL is the one that turns into GPL on iOS, and GPL is the one that "infects" all projects using it so that it becomes useless to for-profit entities.  You're free to do whatever you want with zlib code, including proprietary/commercial projects.

Note that GPL makes piracy a legal right.  That's a big step beyond merely being unable to stop pirates.

Most of what you said I completely agree with though.  I don't want licenses telling me what to do; if I'm going to support the free software movement then I'll go support it, but I don't want it making a legal morass out of my silly little 2D platforming games.
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 01:30:30 am
They don't but devs who don't understand free vs. open difference might end up hating all FOSS licenses, including OSI ones that GNU doesn't approve, when it's just (L)GPL cock blocking certain uses.

As for non tech people, good luck finding one that understands the difference between open source and free software, cares about license/language his software is in and doesn't think Stallman is as stupid as certain mainstream media try to portrait him. Really, really good luck. Ignorant braindead FUD of non tech people also applies to everything that is remotely FOSS.

Sometimes even techs act like morons and spread misinformation, recently I seen comment(of course, untrackable to actual person, under an online chat handle) claiming that he is
Quote
web server admin of a huge server for years and no one ever uses Linux for servers because Windows is more secure, runs faster and Linux has no support or guarantees at all
People like that should get punched in the face by every Red Hat, Novell and Oracle employee. Twice. (That's over a quarter of million of punches, might not be enough for toughest trolls).
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 21, 2013, 01:41:45 am
Well now you're just ranting about stupid/ignorant people being stupid/ignorant.  If someone chooses to hate all FOSS licenses, then they're choosing to never use any software they don't pay money for.  I don't think there's ever going to be a risk of devs shunning all free-as-in-beer software on the planet; not having to pay money is just too huge an incentive.  Whenever scaring people off is a concern, I'm pretty sure you just have to say "free to use even for commercial projects" and that's the end of that.  Also I think portrayals of Stallman are the least of our PR worries with non-tech people, since many of them still think GNU/Linux is a command-line OS.

Maybe we should try to get back on topic.  I'm still really looking forward to getting to use mobile SFML, so here's a stupid question: I know on Android there's a "debug mode" that lets you run programs you make on your PC.  Does iOS have a debug mode or do you have to pay the $99 before you can even test stuff or how does that work?
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 02:06:44 am
Quote
Well now you're just ranting about stupid/ignorant people being stupid/ignorant.
Bah. :P I run into new lows on monthly basis so it's hard not to do that.

Quote
If someone chooses to hate all FOSS licenses, then they're choosing to never use any software they don't pay money for.
Closed program might come gratis, Unity without Pro, GM without GML, UDK(under 50k$ profit, rather risk free solution), IrrKlang for non commercial(and pricing schemes for commercial are very nice). And that's just for programming related, many people pirate Windows, MS Office, AutoCad, Adobe's software etc. and still hate on FOSS alternatives.

Quote
since many of them still think GNU/Linux is a command-line OS.
You mean it's not?  ;D ;D ;D

There is simulator: https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/iOS_Simulator_Guide/Introduction/Introduction.html but according to iforce2d/R.U.B.E. maker who deals with iOS a bit, you can't compile any code on your own actual device whatsoever without buying a license: https://www.iforce2d.net/rube/?panel=loaders


Maybe audio module should remain but have all loaders except direct samples be stubs that always fail? So that desperate people with SFML codebases can get their sound up. That or provide just ogg vorbis support inside SFML to not leave iOS people completely dry?
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 21, 2013, 02:25:20 am
That's what I was afraid of.  Thanks for finding an explicit source on that.

Well there are other iOS applications with audio, so clearly there's some way to get it working.  If libsndfile falls through we may just have to reimplement the audio module using whatever Apple gives us.

I'm not sure why you bring up vorbis because whether a codec is unencumbered has no bearing on this issue.  The code in libsndfile that deals with vorbis is under LGPL, and we'd prefer not to reimplement that from scratch.  Same for all the encumbered codecs.
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 02:55:51 am
Quote
clearly there's some way to get it working
Quote
I'm not sure why you bring up vorbis
;D

Quote
The code in libsndfile that deals with vorbis is under LGPL, and we'd prefer not to reimplement that from scratch.  Same for all the encumbered codecs.
Ogg and voribs come with reference implementations under BSD style license, I doubt libsndfile reimplements them, and neither would we. If libsndfile effort to get permissions fails we might be forced to, at least to provide bare minimum of just ogg vorbis and possibly flac(also BSD style) on iOS.
Title: Re: Android/iOS "Soon"
Post by: Ixrec on October 21, 2013, 03:01:01 am
It'd still be a pain to figure out how to adapt that implementation for SFML's internals, so let's just hope libsndfile works out and we don't have to do any real work.
Title: Re: Android/iOS "Soon"
Post by: FRex on October 21, 2013, 03:07:51 am
I'm not sure but I think only sf::priv::SoundFile uses libsndfile directly so it's not that big a pain, just need few people with strong C-fu to figure it out and vorbis and ogg are nicely documented.

Quote
let's just hope (...) we don't have to do any real work.
YES! ;D
Title: Re: Android/iOS "Soon"
Post by: jagt on October 21, 2013, 03:25:57 pm
After I wrote to the author of libsndfile he said that he would contact all the copyright holders (there seems to be a lot), and make a license exception that would allow static linking on iOS. I'm still waiting for news, so at the moment there's no audio on iOS.

Hi Luarent. Thanks for the feedback! It's good news to know. THe author of libsndfile is really cool too. If that works out it would be so great!
Title: Re: Android/iOS "Soon"
Post by: Gammenon on November 27, 2013, 09:43:00 am
Is there any gross estimation of when will be released that Android/iOS support? I didn't find anything about  that.

Thanks in advance and for SFML!
Title: Re: Android/iOS "Soon"
Post by: Lo-X on November 27, 2013, 09:46:00 am
Is there any gross estimation of when will be released that Android/iOS support? I didn't find anything about  that.

Thanks in advance and for SFML!

According to Laurent, on the french side, you just have to wait a few days. A branch will be pushed on the public repository, then will arrive SFML 2.2 (few time later)
Title: Re: Android/iOS "Soon"
Post by: Laurent on November 27, 2013, 09:48:54 am
Quote
According to Laurent, on the french side, you just have to wait a few days. A branch will be pushed on the public repository, then will arrive SFML 2.2 (few time later)
True. However Jonathan (which is working on the Android port) is very busy so this might take a little longer than expected, but we'll do our best to push something to the repository, even if it's still not complete.
Title: Re: Android/iOS "Soon"
Post by: Gammenon on November 27, 2013, 09:51:23 am
Wow that's fast. Thank you very much guys! :)
Title: Re: Android/iOS "Soon"
Post by: Tank on November 27, 2013, 10:03:18 am
Any reason for not publishing the stuff you already have?
Title: Re: Android/iOS "Soon"
Post by: Laurent on November 27, 2013, 10:12:51 am
Other than Jonathan being busy? No :)

He told me he just had to do one more modification before I can push the code, so it should be fast. Although the audience will be limited because it will only be available in a separate branch of the repository, we want to avoid being spammed with obvious bugs/lacks reports.
Title: Re: Android/iOS "Soon"
Post by: Tank on November 27, 2013, 10:50:22 am
Quote
we want to avoid being spammed with obvious bugs/lacks reports.
I see. Too bad for those who'd like to follow the development though. ;)
Title: Re: Android/iOS "Soon"
Post by: G. on November 27, 2013, 07:01:45 pm
Will there be tutorials? Are they already written?
Title: Re: Android/iOS "Soon"
Post by: Tank on November 27, 2013, 08:57:12 pm
We probably only need some instructions on setting things up for deploying on iOS/Android. The rest of the API should stay the same, I guess.
Title: Re: Android/iOS "Soon"
Post by: Laurent on November 27, 2013, 11:02:00 pm
The documentation and tutorials will of course be updated for the next release.
Title: Re: Android/iOS "Soon"
Post by: NoobsArePeople2 on February 11, 2014, 01:30:42 am
After I wrote to the author of libsndfile he said that he would contact all the copyright holders (there seems to be a lot), and make a license exception that would allow static linking on iOS. I'm still waiting for news, so at the moment there's no audio on iOS.

Have you had any update on this? I'm doing an iOS project for work (using Cocos2d) and saw ObjectAL (https://github.com/kstenerud/ObjectAL-for-iPhone) mentioned as an alternative sound engine to the built-in Cocos2d stuff. Maybe it would be a good fit for SFML iOS (possibly Mac too)?
Title: Re: Android/iOS "Soon"
Post by: Laurent on February 11, 2014, 07:44:24 am
No, no update.