Android and iOS ports available for testing

[Sonkun]

I forgot to mention I also had to move the clear/draw/display calls to the top of the main loop. Probably something goes wrong when calling them after the window has closed.

[cloudncali]

I am currently getting compile errors on the Rpi with the latest SFML build

http://pastebin.com/Be4jJjUs

[Sonkun]

I am currently getting compile errors on the Rpi with the latest SFML build

http://pastebin.com/Be4jJjUs

Thanks, I fixed it locally with another bug. I'll push everything shortly.

@nero81af: I don't understand the changes you made in the EGL implementation. Why would you need that ? As you said, SFML currently only supports version 1.x of OpenGL ES so it shouldn't be necessary.. unless you can't get Ogre working with SFML without it ?

[Laurent]

Thanks, I fixed it locally with another bug

Make sure you're in sync with this commit in another branch.

[Sonkun]

Make sure you're in sync with this commit in another branch.

Don't worry, I am

Sorry for those who are waiting for the changes I announced. I'm delayed because since I rewrote the Android CMake toolchain I can't get libsfml-activity.so to work >.< The audio module is fixed (I managed to compile OpenAL-Soft for Android properly) but I want to recompile libopenal.so again once the toolchain is fixed. There are also small fixes (Raspberry Pi compilation, EGL display is equal to EGL_NO_DISPLAY, etc.) on top of that and I don't want to push before everything works out of the box.

[dk123]

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:

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

[Laurent]

E-mail from Erik, 8 months ago:

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.

[Cranberry]

Would you say that this project has already reached a state where I can "easily" port my current game project to Android or are there still to many bugs to publish a real game in the Play Store?

[dk123]

E-mail from Erik, 8 months ago:

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.

[eXpl0it3r]

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

Already happened.

[Gammenon]

My vote for that change to support WAV, OGG and iOS's formats getting rid of libsnd

[nottrulyevil]

Should a new sub-forum be opened for these ports?

[Laurent]

Should a new sub-forum be opened for these ports?

Why? Is there a Linux, Windows or Mac OS X sub-forum?

[math07]

I've found a bug on Android with texture repeating (using the example) :


The sprite should be exactly 4 SFML logos

Here is the code :

(click to show/hide)

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
#include <SFML/Network.hpp>


int main(int argc, char *argv[])
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "");

    sf::Texture texture;
    if(!texture.loadFromFile("image.png"))
        return EXIT_FAILURE;
    texture.setRepeated(true);

    sf::Sprite image(texture);
    image.setPosition(0, 0);
    image.setOrigin(texture.getSize().x, texture.getSize().y);
    image.setTextureRect(sf::IntRect(0, 0, texture.getSize().x * 2, texture.getSize().y * 2));

    while (window.isOpen())
    {
        sf::Event event;

        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
            {
                window.close();
            }
        }

        if (sf::Touch::isDown(0))
        {
            sf::Vector2i position = sf::Touch::getPosition(0);
            image.setPosition(position.x, position.y);
        }

        window.clear(sf::Color::White);
        window.draw(image);
        window.display();
    }
}
 

[Laurent]

This is not a bug, only a limitation of your GPU, as stated in the doc:

Warning: on very old graphics cards, white pixels may appear
when the texture is repeated. With such cards, repeat mode
can be used reliably only if the texture has power-of-two
dimensions (such as 256x128).

Admitedly, it's not a "very old graphics card", and pixels are not white. But anyway, your platform (don't know if it's your GPU or the GL ES 1.1 spec) doesn't support non-power-of-two texture sizes. So you can't use texture repeating on such textures.