Android and iOS ports available for testing

[leafdj]

Hmm, I'm running into errors recompiling SFML after updating to account for the branch merge.
Right now these are the steps I'm taking:

• Using Cmake GUI on Windows:
• Select source and build paths
• Set ANDROID_NDK variable to point to my Android_NDK path
• Hit Configure- Select MinGW Makefiles and specify toolchain for cross-compiling. Point to the SFML Android toolchain.
• Warnings appear saying "Could not uniquely determine machine name"
• Eh, what are warnings? Generate makefiles successfully.
• Try to run make (both the one included with Cygwin and the one packaged with the NDK, neither worked) in the build dir. Get's to 66% then errors out saying "GL_FUNC_ADD was not declared in this scope"

I was able to build the SFML libs properly for Windows, though that was with running the make included with the Android ndk, which generated a Visual Studio solution that I used to compile it. I previously had the android implementation compiling too, and I don't think I'm doing anything differently this time around.

[math07]

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

Ok, thanks for the answer.

[cloudncali]

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.

Have you pushed it? It appears to still be broken. It looks like the issue is that GL Blend functions arnt supported in GLES 1.x, and SFML uses the GLES 1.x headers in OpenGL.hpp

[myl]

The current master branch does not compile for iOS. I have generated build scripts with the IOS parameter set to true.

JoystickImpl member getIdentification is missing (I see the android version for this was fixed a month ago). In addition I get a couple of GL related errors (ss attached).

myl

[Laurent]

I thought it was already fixed... I'll take care of that ASAP.

[Mario]

There's still a pull request up done by myself, which should fix building on all OpenGL ES platforms: https://github.com/SFML/SFML/pull/580

You don't have to wait for Laurent, just copy the few lines and apply the changes yourself.

[myl]

I thought it was already fixed... I'll take care of that ASAP.

Thanks!

[Mario]

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.

What do you think? Should the unused areas be filled with some pattern or collor? I'd probably make them magenta?

[Laurent]

There's still a pull request up done by myself, which should fix building on all OpenGL ES platforms: https://github.com/SFML/SFML/pull/580

If you make it into a separate pull request (without the Android CMake stuff), and follow the naming conventions (just have a look at all the other identifiers of the GlExtension.hpp file), we can probably merge it quickly

What do you think? Should the unused areas be filled with some pattern or collor? I'd probably make them magenta?

It doesn't matter, because these parts should never be shown.

[Mario]

If you make it into a separate pull request (without the Android CMake stuff), and follow the naming conventions (just have a look at all the other identifiers of the GlExtension.hpp file), we can probably merge it quickly

Happy now? Otherwise just comment on the PR.

It doesn't matter, because these parts should never be shown.

Okay, true.

[Laurent]

Happy now?

No

You PR no longer matches its title and description. You should at least add a message that explains what you changed.

[Mario]

Nitpicka! Fixed.

[Mario]

What do you think regarding the Android sensor implementation? I don't know any reason why the ndk headers haven't been updated, but based on the API version (any minimum defined so far? I'd suggest 9 or 12) pretty much all sensors should be available, even if they're lacking official enum members. For example, the gravity sensor is missing from the official headers, but it's working without any issues (tested on Android 4.4 though).

Apart from those listed already, I'd consider the following sensors to be quite interesting for some games or possibly utility/entertainment software as well: TYPE_LIGHT, TYPE_PRESSURE, TYPE_PROXIMITY, TYPE_TEMPERATURE.

[Laurent]

The set of exposed sensors has been reduced on purpose. Let's start with a small subset of the most common sensors, and add others in future versions.

[Mario]

Okay, the source comment gave me the impression they've been left out just due to (possibly outdated) docs.