Android and iOS ports available for testing

[Laurent]

Which comment?

[Mario]

Code: [Select]

    // These sensors are unavailable from the Android C API
    if ((sensor == Sensor::Gravity) ||
        (sensor == Sensor::UserAcceleration) ||
        (sensor == Sensor::Orientation))
        return NULL;

[Laurent]

Hmm... yes, looks strange.

[AlexAUT]

sf::Music and sf::Sound aren't work on Android for me, is this an known issue? Because everytime I create a instance of Music or SoundBuffer the app crashes (segment fault 11)


AlexAUT

[Hiura]

That might be related to https://github.com/SFML/SFML/issues/621.

[AlexAUT]

That might be related to https://github.com/SFML/SFML/issues/621.

Yeah this fixed my issue.

Another Question: Is it intended that SFML "eats" the volume keys events? Because it's quite annoying when you have to switch out of the app to change the volume of the game.


AlexAUT

[Mario]

Yep, right now it does (and it won't generate key events in SFML). Should probably be something that should be changed for 2.2.

[AlexAUT]

Yep, right now it does (and it won't generate key events in SFML). Should probably be something that should be changed for 2.2.

Yeah i changed the source of SFML so the hardware keys (back, volume) send a key event. Simply added sf::Keyboard::Back, sf::Keyboard::VolumeDown. Without these keycodes its nearly impossible to make a game.

Edit: Is there any "real" case where the app should catch the volume keys?


AlexAUT

[Mario]

Added an issue for this: https://github.com/SFML/SFML/issues/622

There could be use cases where you'd like to control something with the volume keys. Take Amazon's Kindle app as a prime example. It doesn't provide sound output by default. As such they're using "volume up/down" as "page up/down" while reading text, which works rather nice. Of course, there's the touch screen as well, but it's just another option.

It's also possible to use Android phones with VR toolkits such as the Durovis Dive. Once the phone is strapped into the thing it's rather tedious to still access the touch screen, but you could provide minimum control through the (still accessible) volume keys.

[AlexAUT]

Thanks for the examples.

I just noticed that ogg files are still cracking when playing them on android  . I don't want to use wav 


Edit: Normalizing the audio removes the cracking like described here: https://github.com/SFML/SFML/issues/310



AlexAUT

[Sonkun]

Hi,

I rewrote the Android toolchain and pushed the change in feature/android_toolchain. However, there's still a bug and if you compile SFML using this new toolchain, Android won't be able to launch sfml-activity.so. I hope to fix that bug soon (it has to do with link options).

Regarding the audio module which is broken: it's all about compiling OpenAL-Soft properly. Unfortunately there's no official version for Android and our two options are:
* https://github.com/AerialX/openal-soft-android
* https://github.com/apportable/openal-soft
I couldn't make apportable/openal-soft work and managed to make the other one work after disabling some audio backend. The CMake scripts that come along are also a bit broken and need to be hacked to work on some platforms. I'm just waiting for the new Android toolchain to work before recompiling OpenAL-Soft for each arches.

There's also a bad news about the audio module: I never got sf::SoundRecorder working and I really don't know how to fix that. Thus SFML 2.2 might be released without any audio recorder features working on Android.

[Sonkun]

Code: [Select]

    // These sensors are unavailable from the Android C API
    if ((sensor == Sensor::Gravity) ||
        (sensor == Sensor::UserAcceleration) ||
        (sensor == Sensor::Orientation))
        return NULL;

Yes, unless I missed something, these sensors are unavailable from the C API and would require to go trough JNI to use the Java API.

[Mario]

Code: [Select]

    // These sensors are unavailable from the Android C API
    if ((sensor == Sensor::Gravity) ||
        (sensor == Sensor::UserAcceleration) ||
        (sensor == Sensor::Orientation))
        return NULL;

Yes, unless I missed something, these sensors are unavailable from the C API and would require to go trough JNI to use the Java API.

They're only missing from the headers. Using the values from the SDK docs works for me, though.

As for OpenAL, there'd be a third option from a non-github repository. I either linked it here or on the issue tracker. I haven't checked recently, but I think the biggest hurdle is getting a proper config.h (which I have now). Guess biggest question would be which repository us updated regularly (didn't check the ones above so far).

Going to have a look later today.

[Sonkun]

They're only missing from the headers. Using the values from the SDK docs works for me, though.

Awesome! I wasn't aware of that. I added the missing sensor constants and made the remaining sensors available. The change can be found in feature/android_toolchain branch.

As for OpenAL, there'd be a third option from a non-github repository. I either linked it here or on the issue tracker. I haven't checked recently, but I think the biggest hurdle is getting a proper config.h (which I have now). Guess biggest question would be which repository us updated regularly (didn't check the ones above so far).

Does sf::SoundRecorder work with this version of OpenAL-Soft ?

[Mario]

Hm... with latest master I no longer get any audio output and then another segfault after a few seconds.