SFML community forums

General => General discussions => Topic started by: Laurent on November 29, 2013, 03:56:03 pm

Title: Android and iOS ports available for testing
Post by: Laurent on November 29, 2013, 03:56:03 pm
Hi

The iOS/Android ports are finally ready for beta-testing. This happens one month after the expected date, sorry for the delay (everyone is very busy -- more than usual). Until Jonathan pushes the code to the public repository, here is what you need to know if you want to play with them.

Where?

The ports will be available in the ios_and_android branch of the repository. This way it won't bother people who are not interested, and the amount of testers (and reports) is kept under control.

How to compile the iOS port?

To compile the iOS port, you must use the Xcode generator of CMake, and define the "IOS" boolean variable (set to TRUE) before configuring for the first time. The generated projects can then be compiled for x86 (simulator) or armv6/v7 (device) by selecting the target in Xcode; no need to generate multiple builds for that. SFML is built as static libraries on iOS (this is the only option for this OS).

To use SFML in your iOS app project, do as usual: add the include path to your project settings, and drag'n'drop the libraries into your project. Since SFML is linked statically, you'll have to link all its non-default dependencies as well (extlibs/libs-ios).
Note that you'll need a registered Apple developer account in order to copy and run your app on a device; otherwise the simulator will be your only choice.

How to compile the Android port?
How to compile the OpenGL ES port for Linux?
Things to know for Android

Jonathan will explain that as soon as he is available ;)

New API

Only a few things have been added to the public API:

General things to know

The sensors (accelerometer, gyroscope, compass, ...) are currently using the Joystick API (see the sources for more detail about the mapping). We'll soon add a sf::Sensor API that better matches the requirements.

The foreground / background events are mapped to the GainedFocus and LostFocus events.

Orientation changes are mapped to the Resize event.

sf::Shader is not available, because the implementation is based on OpenGL ES 1. Shaders are only available in OpenGL ES 2, which would require a major rewriting of the graphics part. So that won't be done in a near future.

Things to know for iOS

On iOS, the working directory is automatically set to the resources directory.

There's no audio module on iOS, I'm still waiting for libsndfile to add a license exception for iOS so that I can use it statically without breaking the terms of the license. The author said it was one of its priorities, but it was months ago and I've got no news...

The implementation should be compatible with iOS 4.0 and more.

The size of the window is ignored, the screen size is always used.

Examples are not available. It seems that CMake is not ready for that, it still requires too many hacks, and even with them, it was still pretty bad.

The ugly hack: you need to include <SFML/Main.hpp> in the file where your main function is defined. This is because SFML has to hijack it, and rename your own main to call it later.

There's no specific support for high-resolution (retina) screens, they currently produce the same output as low-res screens (this will be done later).

Important

Until everything is merged into master, please use the forum for your feedback. You can post here or open new threads. There are still many things to do, I don't want to pollute the task tracker ;)
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on November 29, 2013, 04:42:45 pm
Note

For those who aren’t familiar with git, once the SFML repo freshly cloned, type: git checkout –b ios_and_android origin/ios_and_android to get the right branch.

How to compile the Android port?

To compile the Android port, you must use CMake with the toolchain configuration script located at cmake/toolchains/android.toolchain.cmake. To do that, define the CMAKE_TOOLCHAIN_FILE variable when invoking CMake and make it point to the android.toolchain.cmake script. You’ll also need to define an environments variable ANDROID_NDK telling where the NDK directory is. There are a few options available to customize the build process:

ANDROID_ABI : armeabi, armeabi-v7a, x86, mips
ANDROID_NATIVE_API_LEVEL:  9, 14, 18, etc.
ANDROID_USE_STLPORT: Make sure this one is set at TRUE because I’m not sure if it’s set automatically. Usage of the STL port is MANDATORY. If you don’t use it, no error will be reported and your application will just.. crash :)

Once compiled, type "make install" to install everything in your NDK directory.

Getting familiar with the compilation process of native Android application isn’t an easy task so, don’t give up and read carefully the NDK documentation. Maybe you should start with compiling an official example such as NativeActivty located in your NDK. You’ll need to get through this because you won’t be able to reuse this CMake toolchain script to compile your own application (unless your application is a library :D).

There’s an example available in the SFML source files directory. I advise you to “create a project from existing source” from the Android IDE (Eclipse). Once the example imported and set up, you can’t simply press the “Run” button, you’ll need to compile the example project first. To do that, open a console, head to the example directory and invoke the ndk-build script located in your NDK:  your command might look like this: $ANDROID_NDK/ndk-build

Things to know for Android

On Android, the working directory is automatically set to the resources directory (assets/).

sf::SoundRecorder won’t record any sounds.

Since recently I no longer get the orchestral.ogg song to play with sf::Music ... but canary.wav does work.

The implementation is compatible with Android 9 or later.

You may have to install some 32bits libs on Linux. I can’t tell which exactly but on Fedora 64bits, type the following: sudo yum install glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686. If someone could give the list for Debian based distribution, it would great!

How to compile the OpenGL ES port for Linux?

Unfortunately, this isn’t available yet because I need to refactor the EGL code to avoid duplication, as well as time to test the new CMake scripts on a Raspberry Pi. I’ll implement this really soon.

Important

I really am busy right now and I won't be able to provide much support until 8th of December.
Title: Re: Android and iOS ports available for testing
Post by: Tank on November 29, 2013, 06:08:29 pm
First: Thanks for your work. :)

I tried to build SFML, however I get errors inside the NDK. Since I'm very unexperienced with it, I ask if something like this is known anyhow:

Code: [Select]
cd /home/stefan/build/sfml-android-release/src/SFML/System && /home/stefan/android-ndk-r9b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++   -DANDROID -DSFML_OPENGL_ES -DSFML_SYSTEM_EXPORTS -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5__ --sysroot=/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm -fsigned-char -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -fPIC -Wno-psabi -frtti -fno-exceptions -mthumb -O3 -fomit-frame-pointer -DNDEBUG -fPIC -isystem /home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include -isystem /home/stefan/android-ndk-r9b/sources/cxx-stl/stlport/stlport -I/home/stefan/projects/SFML/include -I/home/stefan/projects/SFML/src    -fvisibility=hidden -o CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o -c /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp
In file included from /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.hpp:33:0,
                 from /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:29:
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:86:43: error: 'size_t' has not been declared
 int AAsset_read(AAsset* asset, void* buf, size_t count);
                                           ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:94:1: error: 'off_t' does not name a type
 off_t AAsset_seek(AAsset* asset, off_t offset, int whence);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:105:1: error: 'off64_t' does not name a type
 off64_t AAsset_seek64(AAsset* asset, off64_t offset, int whence);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:122:1: error: 'off_t' does not name a type
 off_t AAsset_getLength(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:128:1: error: 'off64_t' does not name a type
 off64_t AAsset_getLength64(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:133:1: error: 'off_t' does not name a type
 off_t AAsset_getRemainingLength(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:140:1: error: 'off64_t' does not name a type
 off64_t AAsset_getRemainingLength64(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:150:46: error: 'off_t' has not been declared
 int AAsset_openFileDescriptor(AAsset* asset, off_t* outStart, off_t* outLength);
                                              ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:150:63: error: 'off_t' has not been declared
 int AAsset_openFileDescriptor(AAsset* asset, off_t* outStart, off_t* outLength);
                                                               ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:161:48: error: 'off64_t' has not been declared
 int AAsset_openFileDescriptor64(AAsset* asset, off64_t* outStart, off64_t* outLength);
                                                ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:161:67: error: 'off64_t' has not been declared
 int AAsset_openFileDescriptor64(AAsset* asset, off64_t* outStart, off64_t* outLength);
                                                                   ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::seek(sf::Int64)':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:66:43: error: 'AAsset_seek' was not declared in this scope
     AAsset_seek(m_file, position, SEEK_SET);
                                           ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::tell()':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:73:56: error: 'AAsset_getRemainingLength' was not declared in this scope
     return getSize() - AAsset_getRemainingLength(m_file);
                                                        ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::getSize()':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:80:35: error: 'AAsset_getLength' was not declared in this scope
     return AAsset_getLength(m_file);
                                   ^
src/SFML/System/CMakeFiles/sfml-system.dir/build.make:402: recipe for target 'src/SFML/System/CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o' failed
make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o] Error 1
make[2]: Leaving directory '/home/stefan/build/sfml-android-release'
CMakeFiles/Makefile2:108: recipe for target 'src/SFML/System/CMakeFiles/sfml-system.dir/all' failed
make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
make[1]: Leaving directory '/home/stefan/build/sfml-android-release'
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

CMake config: See attached image.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on November 29, 2013, 06:18:00 pm
It seems that NDK version r9b has been released in the meantime. I use version r9 so try to downgrade, even if it's unlikely to be because of this new version.

Try:
export ANDROID_NDK=/path/to/ndk
cd SFML/
mkdir build && cd build
cmake -CMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 ..
make -j8
Title: Re: Android and iOS ports available for testing
Post by: Tank on November 30, 2013, 01:10:46 pm
Thanks, will try that.

-j8? I only have 4 gigs of RAM, do you want to freeze my system? :P

Edit: I was able to build SFML with NDK version 9.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on November 30, 2013, 03:15:55 pm
Hey, so I followed the Android instructions, nearly the same as for eSFML, so I don't think I did something wrong.

I created a project from the android example, added native support, then compiled it, everything works fine until my phone tries to launch the application.

Here are the logcat logs, I tried it on two phones: Galaxy S (android 2.3.4), and HTC ONE X (tegra 3) (Android 4.2.2).

HTC one X
11-30 14:48:18.740: E/(22467): file /data/data/com.nvidia.NvCPLSvc/files/driverlist.txt: not found!
11-30 14:48:18.745: I/(22467): Attempting to load EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:18.765: I/(22467): Loaded EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:19.310: D/NvOsDebugPrintf(22467): Library for API 1 exposes function not wrapped: glPointSizePointerOES
11-30 14:48:19.315: I/(22467): Loading GLESv1_CM implementation /system/lib//egl/libGLESv1_CM_tegra_impl
11-30 14:48:19.465: A/libc(22467): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22489 (om.example.sfml) - sent from sys


Samsung Galaxy S:
11-30 14:48:18.740: E/(22467): file /data/data/com.nvidia.NvCPLSvc/files/driverlist.txt: not found!
11-30 14:48:18.745: I/(22467): Attempting to load EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:18.765: I/(22467): Loaded EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:19.310: D/NvOsDebugPrintf(22467): Library for API 1 exposes function not wrapped: glPointSizePointerOES
11-30 14:48:19.315: I/(22467): Loading GLESv1_CM implementation /system/lib//egl/libGLESv1_CM_tegra_impl
11-30 14:48:19.465: A/libc(22467): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22489 (om.example.sfml) - sent from sys

 


On a emulator it just get stuck during the launching phase with no error.


P.S. I compile it again to exclude a mistake in the setup

AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on November 30, 2013, 05:03:19 pm
Quote
added native support
???

You don't need to right-click on the project then "Add native support...". I'll explain how it works internally later.

Quote
P.S. I compile it again to exclude a mistake in the setup
Does that mean it works now? :D
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on November 30, 2013, 08:51:55 pm
No its still not working yet. The ndk examples runs fine, so I guess its not an error in my setup (at least the sdk/ndk part)

When I do not add native support I get an error the phone cant find the shared library...


Btw i test it on windows, tomorrow I will try it on ubuntu...


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on November 30, 2013, 10:34:48 pm
For now, you're forced to have your application library named "sfml-example" (libsfml-example.so) because the SFML Activity (libsfml-activity.so) that comes along when you compile SFML doesn't take the customized application name into account.

In the meantime, you can either modify Main/SFMLActivity.cpp line 145 or fix it :D

Good luck!
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on November 30, 2013, 10:43:47 pm
Ok i am currently not at home, out clubbing  ;)

But thanks for your help I will try it later!



Edit: I downgraded my NDK from 9b to 9 and set everything up again and now it works(without setting the native lib support)... Awesome work!



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: binary1248 on December 01, 2013, 11:42:35 am
So... since this should also be compilable on a normal system, I went ahead and tried it out.

Didn't compile because <SFML/System/Err.hpp> was missing from GLExtensions.cpp for err() and std::endl.

Fixed that, then went ahead to check out all the warnings I got with my crazy warning settings enabled :).
Code: [Select]
-Wall -Wextra -Wconversion -Wshadow -Wunreachable-code -Wredundant-decls -Wcast-align -Wfloat-equal -Wno-long-long -Wformat=2 -pedantic
First and most importantly, is it necessary to redefine the OpenGL extension function names even if they exist already? From what I understand, the suffix added to the function names just denote which vendor/working group is taking care of the extension before it gets reviewed by the ARB and then put into the core specification. So overwriting say glGenFramebuffers with glGenFramebuffersEXT doesn't seem right to me if glGenFramebuffers already exists. Wouldn't it be nicer to have some form of #if !defined() guards around each function?

I also went ahead and cleaned out many conversion warnings that popped up. Most conversions shouldn't have made a change to behaviour, but some others do in fact change behaviour in slight ways that were probably not noticed by anyone yet ;). Free "bug" fixes.

Here is the diff. When I push my branch to GitHub it completely messes up the line endings, because well... SFML line endings are a mess already :P. Laurent or someone should just tell git to normalize them one day, see: https://help.github.com/articles/dealing-with-line-endings

Patch here: patch.diff (http://pastebin.com/UWTXkdTT)
Title: Re: Android and iOS ports available for testing
Post by: wintertime on December 01, 2013, 12:05:53 pm
As I read up on ARB_framebuffer_object and EXT_framebuffer_object recently, I can say they are subtly incompatible and should not be mixed up, because they have different internal code. The EXT version gets shared beweens contexts, while the ARB (or GL3.0) version does not and contains other extensions. One should not call functions of one of them, then functions of the other.
And its not the only extension where older extensions were modified, not just promoted.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 01, 2013, 04:07:52 pm
Quote
Didn't compile because <SFML/System/Err.hpp> was missing from GLExtensions.cpp for err() and std::endl.
Ah. Strange thing that it compiled for me (I can understand how <iostream> may be included indirectly depending on the compiler/OS, but <System/Err.hpp>?).

Quote
First and most importantly, is it necessary to redefine the OpenGL extension function names even if they exist already? From what I understand, the suffix added to the function names just denote which vendor/working group is taking care of the extension before it gets reviewed by the ARB and then put into the core specification. So overwriting say glGenFramebuffers with glGenFramebuffersEXT doesn't seem right to me if glGenFramebuffers already exists. Wouldn't it be nicer to have some form of #if !defined() guards around each function?
Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.

Quote
I also went ahead and cleaned out many conversion warnings that popped up. Most conversions shouldn't have made a change to behaviour, but some others do in fact change behaviour in slight ways that were probably not noticed by anyone yet
I don't understand why so many casts would be needed. As far as I know, "anything op float" yields a float, so there's no need to cast both operands every time.

Quote
SFML line endings are a mess already :P. Laurent or someone should just tell git to normalize them one day, see: https://help.github.com/articles/dealing-with-line-endings
Yep. I thought I had configured git correctly... obviously not.
Title: Re: Android and iOS ports available for testing
Post by: binary1248 on December 01, 2013, 04:44:18 pm
Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.
But the problem is, it will never be defined in the GL header, at least on Windows, unless Microsoft decides that Windows should support a more recent version of OpenGL than what... 1.1? That would break all their precious customers' systems who don't have cards that can support anything more recent, which is also why DirectX has a hardware emulation layer. If OpenGL had a software rasterizer fallback that took care of newer features it wouldn't be a problem to do so, but it isn't part of the standard and Microsoft hasn't shown any interest in it either.

This is why GLEW goes ahead and defines even core functions. The goal is that every extension that is proposed goes through a sort of standardization process.

First it is probably only supported by a single vendor AMD/Nvidia, then it has the NV or ATI/AMD suffix.
Once the vendor can convince other vendors that what they are doing is good, it gets the EXT suffix.
When it is submitted to ARB for becoming part of the core API, it gets the ARB suffix.
Finally when it gets into the core specification it loses all suffixes.

The function will stay in the GLEW header, probably forever, but over time it will change its name, and maybe even its functionality a bit.

The only reason why the redefinitions that are in GLExtensions.hpp work now, is because the assumption that "if the card supports the core function it supports the EXT variant as well" holds. As wintertime already said, this can be problematic because they are not required to have the same behaviour, and it is up to the card manufacturers to drop support for legacy APIs if they have had core support for a long time. It might just be that at some point glGenFramebuffers will be available from GLEW, but glGenFramebuffersEXT not, and with those redefinitions you are overwriting a working name with a non-working one. This will break things because the redefinition takes place after you include GLEW the first time and if the compiler can't find the definition of glGenFramebuffersEXT after the preprocessor replaces glGenFramebuffers with it, or even worse tries to call glGenFramebuffersEXT although it is not set up, bad things will happen.

I think if you need a common entry point for those different GL functions you should create your own name block for it, something like SFGenFramebuffers and use the GLEW extension probing macros to decide which to assign to it, favouring core functions of course. This is how many other libraries alias lower level functionality in such situations.

I don't understand why so many casts would be needed. As far as I know, "anything op float" yields a float, so there's no need to cast both operands every time.
In the case of a binary operation, yes that is true, but it is also a matter of signalling the programmer's intention, and technically, if you cast one operand on the right-hand-side just to get a floating point operation, you are losing precision over casting the result after the integer operation instead.

When there are more operands involved it sometimes isn't always obvious in what order the implicit casts will take place. The goal is to cast as late as possible to take advantage of lossless integer operations but early enough if you know an integer operation will lose precision because it can lead to a fractional value.

I've just made it a habit to explicitly specify casts for everything so I know exactly what happens. Leaving things up to the compiler to decide works most of the time, but when higher level semantic knowledge gets involved, the compiler doesn't really have many possibilities to be smart about how it generates code, especially in a case where the standard instructs it to do something we didn't expect.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 01, 2013, 05:34:07 pm
Quote
But the problem is, it will never be defined in the GL header, at least on Windows
But things are not limited to Windows, as you perfectly know ;)

Regarding casts: if nothing's broken then I prefer leaving the code as it is now. I'm not a big fan of those long lines of code where 80% of space is taken by occurences of the "static_cast" keyword. Of course your approach is safer, but I think it's a point where I can make a compromise ;)
Title: Re: Android and iOS ports available for testing
Post by: binary1248 on December 01, 2013, 05:44:39 pm
But things are not limited to Windows, as you perfectly know ;)
But Windows is supported, and should not break even in such situations, as you perfectly know ;)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 01, 2013, 07:25:15 pm
Quote
But Windows is supported, and should not break even in such situations, as you perfectly know
I just said that your solution based on the preprocessor might not work on Linux and OS X. I never said that I didn't want to solve this issue; sorry if it was not clear.

Quote from: Laurent
Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.
Title: Re: Android and iOS ports available for testing
Post by: binary1248 on December 01, 2013, 09:02:07 pm
I just said that your solution based on the preprocessor might not work on Linux and OS X. I never said that I didn't want to solve this issue; sorry if it was not clear.
Why wouldn't it work? The names are part of the OpenGL extensions that are quasi-standard and the preprocessor should work the same on all platforms unless you have a really broken compiler ;). I haven't seen any special versions of said functions that only exist on a certain platform... There is only one GLEW header that you use on all platforms and it defines the same functions that are available.

Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.
Actually, now that I checked, when you include glew.h it basically "pretends to be gl.h" by defining __gl_h_ itself so that if you include gl.h after glew.h it does nothing. If you do the opposite and include gl.h before glew.h an #error will be triggered so that isn't even possible. So as long as you include glew.h you will have access to all the functions and definitions no matter what gl.h version you have. There is no way to prioritize one or the other. You can't use both at the same time anyway, either you use glew.h or gl.h but not both.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 01, 2013, 09:17:53 pm
Quote
Why wouldn't it work? The names are part of the OpenGL extensions that are quasi-standard and the preprocessor should work the same on all platforms unless you have a really broken compiler ;). I haven't seen any special versions of said functions that only exist on a certain platform... There is only one GLEW header that you use on all platforms and it defines the same functions that are available.
If you include an OpenGL 2+ header, it will declare these functions directly, not as macros. The preprocessor won't see them, and your test will fail although the functions are already defined.

Quote
Actually, now that I checked, when you include glew.h it basically "pretends to be gl.h" by defining __gl_h_ itself so that if you include gl.h after glew.h it does nothing. If you do the opposite and include gl.h before glew.h an #error will be triggered so that isn't even possible. So as long as you include glew.h you will have access to all the functions and definitions no matter what gl.h version you have. There is no way to prioritize one or the other. You can't use both at the same time anyway, either you use glew.h or gl.h but not both.
Interesting. So I guess this closes the discussion ;)

I'll rename my own identifiers so that no confusion / conflict is possible anymore.
Title: Re: Android and iOS ports available for testing
Post by: Lo-X on December 02, 2013, 11:09:33 am
Hell yeah, I'll test that android port this evening !

Thanks a lot to all of you for the job done ! That's amazing =)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 02, 2013, 11:31:41 am
Nobody for iOS? :'(
Title: Re: Android and iOS ports available for testing
Post by: eXpl0it3r on December 02, 2013, 11:56:30 am
Nobody for iOS? :'(
We don't sell our souls to Apple. :P
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 02, 2013, 12:00:38 pm
Let's see the positive side of this situation: more work for Jonathan, less work for me ;D
Title: Re: Android and iOS ports available for testing
Post by: Lo-X on December 02, 2013, 01:52:06 pm
Let's see the positive side of this situation: more work for Jonathan, less work for me ;D

Of course my thanks were for the iOS port too, but like eXpl0it3r, I do not use any apple devices so I can't test it.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on December 02, 2013, 01:58:37 pm
So I have tried to port Kroniax for Android, and found a few bugs in SFML   ::)


1.) The SFML app crashes when you try to change the orientation, e.g. turn the phone to landscape mode. Error code in logcat: "validate_display:294 error 3008 (EGL_BAD_DISPLAY)"

Current fix: Force one orientation, e.g. "android:screenOrientation="landscape" "

2.)sf::Sprite doesn't support transparent images, the transparent pixels are black or white instead of transparent. Also the non transparent colors aren't drawn correctly. See attachments(the sprite in the app, and the raw image)

3.)I think Jonathan already mentioned it that sf::Music can't play *.ogg files. the openFromFile always return false.

4.)I dont know if its just because of the license of GNUSTL(good c++11 support) but it would be nice if SFML wouldn't force us to use the STLPORT(little c++11 support). (not really a bug)

EDIT:
5.)Fonts/Text seems not to work too -> (http://i.imgur.com/fx9lCMg.png)


But anyway great work, thanks!


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 02, 2013, 02:56:19 pm
Nobody for iOS? :'(
I'll probably try later. :) I've been waiting on this for a while.

I only have access to the simulator though.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 02, 2013, 03:52:49 pm
Quote
I only have access to the simulator though.
For those who don't know: you can also run your compiled apps on a jailbroken device.
Title: Re: Android and iOS ports available for testing
Post by: lockandstrike on December 02, 2013, 05:38:04 pm
I'm trying to build the android port but it is not working. Cmake says that the CMAKE_TOOLCHAIN_FILE  isn't being used by the project
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 02, 2013, 06:22:19 pm
There

At first it was having issues finding the OS X 10.9 SDK. I don't know if it is my computer, but I found it in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk". I think it has something to do with XCode coming through the app store now, but that's just a random guess.

Then I had this:
CMake Error at CMakeLists.txt:231 (install):
  install FILES given no DESTINATION!


CMake Error at CMakeLists.txt:232 (install):
  install FILES given no DESTINATION!


Configuring incomplete, errors occurred!
See also "/Users/Chase/Desktop/Programming/build/SFML-ios/CMakeFiles/CMakeOutput.log".
See also "/Users/Chase/Desktop/Programming/build/SFML-ios/CMakeFiles/CMakeError.log".
After looking at CMakeLists.txt I tried defining INSTALL_MISC_DIR manually, which worked.

Also this. (https://github.com/SFML/SFML/commit/24aa04fd4cebb9b44cbac41154fdbb497b97e7ca#commitcomment-4748774)

Other than that it built successfully, but I'll have to actually try it another time later today.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 02, 2013, 08:47:20 pm
Quote
I think it has something to do with XCode coming through the app store now
Hmm I've never had problems with that. My Xcode was installed with the app store too, and as far as I remember the SDK was found at the same location -- automatically of course.
However I'm not up-to-date: Xcode 4.6 (I think ;D) and OS X 10.7.

Quote
After looking at CMakeLists.txt I tried defining INSTALL_MISC_DIR manually, which worked.
Fixed.

Quote
Also this.
Fixed.

Thank you :)
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 02, 2013, 11:10:44 pm
Quote
I think it has something to do with XCode coming through the app store now
Hmm I've never had problems with that. My Xcode was installed with the app store too, and as far as I remember the SDK was found at the same location -- automatically of course.
However I'm not up-to-date: Xcode 4.6 (I think ;D) and OS X 10.7.
I'm using Xcode 5.0.1 and OS X 10.9. I really have no clue what it is then. I don't have much experience with anything beyond a couple of experiments here and there.

So I tried a simple test app, and when it linked it gave some errors until I added the non-default libraries from here (https://github.com/SFML/SFML/blob/ios_and_android/src/SFML/Window/CMakeLists.txt#L184). It took me a while to figure that out and how to do it (properly), but I suppose it doesn't help that I haven't used XCode much since sometime in OS X 10.5/6.

Now that it is running all I get is a black screen for this:
Code: [Select]
#include <SFML/Main.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>

int main( int argc, const char* argv[] )
{
sf::RenderWindow window( sf::VideoMode( 0, 0 ), "Testing SFML" );
//window.setFramerateLimit( 50 );

sf::RectangleShape shape;
shape.setSize( sf::Vector2f( 100, 100 ) );
shape.setPosition( 50, 50 );
shape.setFillColor( sf::Color::Blue );

bool isRunning = true;
while ( isRunning )
{
sf::Event event;
while ( window.pollEvent( event ) )
{
//
}

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

return 0;
}
The only iOS SDK I have available is 7.0 (simulator 7.0.3), so I wasn't able to test on anything else.

Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 03, 2013, 07:28:53 am
Quote
So I tried a simple test app, and when it linked it gave some errors until I added the non-default libraries from here.
Oops, this is an important thing that I forgot to explain ;D Since SFML is linked statically, you have to link its dependencies yourself in your application.

Quote
Now that it is running all I get is a black screen for this
What if you use a valid size for the window? It is ignored by the window, but I think the default view still uses it.
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 03, 2013, 03:16:22 pm
Oops, this is an important thing that I forgot to explain ;D Since SFML is linked statically, you have to link its dependencies yourself in your application.
Oh, that makes since. I don't link statically very often, and when I have I did it before that was needed on Windows. :P

What if you use a valid size for the window? It is ignored by the window, but I think the default view still uses it.
I was originally using (640, 480), but was trying to change it to see if something different would happen.

Shouldn't the screen at least be white though, since I'm clearing with sf::Color::White? I can't remember if that works with OpenGL ES, it has been a while since my attempt at it.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 03, 2013, 06:25:59 pm
Quote
Shouldn't the screen at least be white though, since I'm clearing with sf::Color::White?
This may be the splash screen that automatically appears until the app is ready to run. Try to provide a custom one.
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 04, 2013, 05:51:09 pm
This may be the splash screen that automatically appears until the app is ready to run. Try to provide a custom one.
It shows up for a second and fades then fades to black.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 04, 2013, 06:02:00 pm
You can also try iOS 6 instead of 7: in your project properties, select iOS 6 for "deployment target", and in the simulator, select iOS 6 too.
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 04, 2013, 07:59:24 pm
That was obnoxious. (https://github.com/SFML/SFML/pull/503)

Anyways, Starbound is out. I'm going to be fairly distracted now. :P

(EDIT: I guess I should make it a little bit more clear, it does work now.)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 04, 2013, 09:11:53 pm
Great! :D
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 05, 2013, 02:15:07 am
Example app is crashing (SIGSEGV) for me using SDK 17 and 19 with NDK r9 (Asus Transformer Prime, Android 4.1.1):
Code: [Select]
I/DEBUG   (27754): backtrace:
I/DEBUG   (27754):     #00  pc 0000fc2a  /system/lib/libutils.so (android::String8::appendPath(char const*)+5)
I/DEBUG   (27754):     #01  pc 00018c6d  /system/lib/libandroidfw.so (android::AssetManager::open(char const*, android::Asset::AccessMode)+52)
I/DEBUG   (27754):     #02  pc 000089f9  /system/lib/libandroid.so (AAssetManager_open+28)
I/DEBUG   (27754):     #03  pc 0000a983  /data/data/com.example.sfml/lib/libsfml-system.so (sf::priv::ResourceStream::ResourceStream(std::string const&)+58)

The previous ESFML build worked without problems. The crash happens for both resources, the image as well as the audio file.

Edit:
My bad, obviously forgot to set ANDROID_USESTLPORT and it's working now. :)
Title: Re: Android and iOS ports available for testing
Post by: CptZouglou on December 06, 2013, 11:21:10 pm
Hi there,

Thanks for the port ! I will try both android and iOS very soon (or when I have time...) . Simulator, iPhone and iPad :)

Good luck with that.
Title: Re: Android and iOS ports available for testing
Post by: aratnon on December 07, 2013, 03:33:49 am
Is the stable version available soon? I would like to use SFML for my Android game project.
Title: Re: Android and iOS ports available for testing
Post by: eXpl0it3r on December 07, 2013, 10:10:11 am
Is the stable version available soon? I would like to use SFML for my Android game project.
The more you help us stabilize it, the sooner it will be ready. ;)
Soon Jonathan will have time to go over the reports and we'll see where we can go from there.
Title: Re: Android and iOS ports available for testing
Post by: spacechase0 on December 08, 2013, 10:35:31 pm
Playing with it some more, hopefully with less silly mistakes. It seems there might be an issue with sf::Event::LostFocus on iOS. Using this:

#include <iostream>
#include <SFML/Main.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Window.hpp>

int main( int argc, char* argv[] )
{
        sf::RenderWindow window( sf::VideoMode( 1, 1 ), "Testing SFML" );
        window.setFramerateLimit( 50 );
       
        sf::RectangleShape shape;
        shape.setSize( sf::Vector2f( 100, 100 ) );
        shape.setPosition( 50, 50 );
        shape.setFillColor( sf::Color::Blue );
       
        std::cout << "start" << std::endl;
        bool isRunning = true;
        while ( isRunning )
        {
                sf::Event event;
                while ( window.pollEvent( event ) )
                {
                        if ( event.type == sf::Event::LostFocus )
                        {
                                isRunning = false;
                        }
                }
               
                shape.move( 0, 2 );
                std::cout << "loop " << shape.getPosition().y << std::endl;
               
                window.clear( sf::Color::White );
                window.draw( shape );
                window.display();
        }
        std::cout << "term" << std::endl;
       
        return 0;
}

The program runs fine. When leaving the app, "loop <...>" stops appearing, but "term" does not appear. When reopening it, "term" appears and the screen stays black.

If I leave and reopen again, instead of rerunning the app, it crashes with EXC_BAD_ACCESS here (https://github.com/SFML/SFML/blob/ios_and_android/src/SFML/Window/iOS/SFAppDelegate.mm#L170).

Also, it when loading a font I get 'Failed to load font "Arial.ttf" (failed to create the font face)'. I'm not sure if I put it on the wrong place though, I'll have to look more into it later.

Sprites/textures and touch events worked very well though. :) My testing has been pretty simple so far.
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 08, 2013, 10:43:08 pm
Font loading is broken at the moment, same happens for Android.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on December 09, 2013, 06:34:58 am
Thanks for waiting! I'm now available to dig into these issues :D

So, what do we have here:

1) Crash when orientation changes (unless you set android:screenOrientation at landscape)
2) Alpha color issue
3) Figure out why some audio format cannot be played.
4) Drop stlport in favor of gnustl since it has poor C++11 support
5) sf::Text displays white rectangles
6) Add support for NDKr9b

Bug number 2 and 5 are fixed but I haven't pushed anything yet because I need confirmation from the iOS port.

Quote
I'm trying to build the android port but it is not working. Cmake says that the CMAKE_TOOLCHAIN_FILE  isn't being used by the project
This message shows up when I rerun CMake so don't worry, it's being used by the project.

Quote
Font loading is broken at the moment, same happens for Android.
What happens exactly? Does it fail to load any font file ? Or is it the same as bug number 5 ?

Quote
Is the stable version available soon? I would like to use SFML for my Android game project.
I just finished porting my game so I guess it's stable enough to start developing a game :D
 
Thanks everyone for your feedbacks and reports! :)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on December 09, 2013, 07:46:31 am
Quote
When leaving the app, "loop <...>" stops appearing, but "term" does not appear. When reopening it, "term" appears and the screen stays black.
iOS apps crash if you terminate them. That's a know bug.

Quote
Font loading is broken at the moment
No it's not, I've never had any problem with fonts on iOS. It's most likely a resource directory issue (try to load a texture for example).
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 09, 2013, 09:56:36 am
Quote
Font loading is broken at the moment, same happens for Android.
What happens exactly? Does it fail to load any font file ? Or is it the same as bug number 5 ?

Unicolored quads, exactly. Size, offsets, etc. are perfectly fine, just missing transparency and/or texture coordinates (didn't check so far).

Quote
Font loading is broken at the moment
No it's not, I've never had any problem with fonts on iOS. It's most likely a resource directory issue (try to load a texture for example).
[/quote]

Well, on Android. :) See above.
Title: Re: Android and iOS ports available for testing
Post by: eigenbom on December 10, 2013, 03:17:00 am
It's great to see these ports coming along! I've compiled the libs for ios, but haven't got around to testing a basic application yet. Hopefully I'll get a chance soon.
Title: Re: Android and iOS ports available for testing
Post by: Canadadry on December 14, 2013, 11:49:16 am
Hi,
I'm on the iOS port too.  :D
I've tried to build it whitout any succes. 
First error that pops to me : it can't find <GL/glew.h> to fix it I had to modified XCode projet and add a user search Path to the extlibs/header you've provided.
Then it couldn't find <OpenGL/glu.h> and I don't know why.... I will look further more later.

I've recently moved to Maverick via update and install the last XCode (5.something) through AppStore. So it's might be to link to all of this. Maybe a clean install will help....  :(
Still, I'm eager to try this ^^

Thanks for the work you've done.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on December 14, 2013, 01:58:58 pm
Bug number 2 and 5 are fixed but I haven't pushed anything yet because I need confirmation from the iOS port.

Can't wait for the fixes to be public repo because currently it is impossible to use the Android port (sf::Text and sf::Sprite issue).


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on December 15, 2013, 06:18:26 pm
I'll send a fix tonight with the EglContext code improvaed and refactored to be used on Linux and other EGL based OSes.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on December 16, 2013, 01:59:05 pm
I ended up with changes in some CMake scripts and I still need to test whether SFML compiles okay on Windows before pushing anything. It should be ready tonight!
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 16, 2013, 02:14:19 pm
Push it and drop me a PM, it's an experimental/unstable branch after all. :)
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on December 16, 2013, 02:54:31 pm
Unfortunately I don't have access to the code right now so I can't push it :( By the way, rewriting commits leads to confusion, that's why I prefer to wait in general :p

If you're looking for the code that fixes the font and transparency issue, I haven't fixed it properly yet actually... (not sure if it'd still work on the iOS side). Anyways, here's a quick temporary fix: replace "GL_OES_blend_func_separate" with "false" in Egl src/SFML/Graphics/GlExtensions.hpp lin 37.

You may have to set EGL_BIND_TO_TEXTURE_RGBA at True in src/SFML/Window/Android/EglContext.cpp (be careful there are three occurrences).

I'll sort this thing out tonight before pushing EglContext refactored :)
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 16, 2013, 03:00:43 pm
Can wait, just thought you're just waiting for someone to test the commit.
Title: Re: Android and iOS ports available for testing
Post by: iroquai_tribe on December 19, 2013, 04:52:16 pm
Thanks for the last commit Sonkun. I will try it on my RPi this weekend!  :)
Title: Re: Android and iOS ports available for testing
Post by: iroquai_tribe on December 20, 2013, 12:28:43 pm
Hi all! I tried to compile on my PI and got this:

Quote
Scanning dependencies of target sfml-window
[ 18%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/Context.cpp.o
[ 20%] Building CXX object src/SFML/Window/CMakeFiles/sfml-window.dir/GlContext.cpp.o
In file included from /home/pi/Documents/sfmlDec2013/SFML/src/SFML/Window/GlContext.cpp:70:0:
/home/pi/Documents/sfmlDec2013/SFML/src/SFML/Window/EglContext.hpp:151:12: error: ‘XVisualInfo’ does not name a type
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/GlContext.cpp.o] Error 1
make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
make: *** [all] Error 2

I added "-DSFML_OPENGL_ES=1" to cmake so it would include
Quote
-- Found EGL: /usr/lib/arm-linux-gnueabihf/libEGL.so 
-- Found GLES: /usr/lib/libGLESv1_CM.so 

instead of

Quote
-- Looking for XOpenDisplay in /usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so
-- Looking for XOpenDisplay in /usr/lib/arm-linux-gnueabihf/libX11.so;/usr/lib/arm-linux-gnueabihf/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found X11: /usr/lib/arm-linux-gnueabihf/libX11.so
-- Found OpenGL: /usr/lib/arm-linux-gnueabihf/libGL.so 
-- Found GLEW: /usr/lib/arm-linux-gnueabihf/libGLEW.so 

I tried to get around the need of XVisualInfo but I couldn't do it. Any help is greatly appreciated :)
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 20, 2013, 12:30:47 pm
Bit confused right now: Are text glyphs supposed to be fixed now on Android?
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on December 21, 2013, 05:34:56 pm
Bit confused right now: Are text glyphs supposed to be fixed now on Android?

Don't think so. Only the Linux Opengl es implementation is now available (latest commit).

But here is the fix for the android text issue:

If you're looking for the code that fixes the font and transparency issue, I haven't fixed it properly yet actually... (not sure if it'd still work on the iOS side). Anyways, here's a quick temporary fix: replace "GL_OES_blend_func_separate" with "false" in Egl src/SFML/Graphics/GlExtensions.hpp lin 37.

You may have to set EGL_BIND_TO_TEXTURE_RGBA at True in src/SFML/Window/Android/EglContext.cpp (be careful there are three occurrences).


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 21, 2013, 05:44:24 pm
Ah okay, haven't had time to look whether that commit is in there already.
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on January 03, 2014, 11:11:56 pm
Whenever I try to use cmake on ubuntu I get the following results:

The commands I use are:
export ANDROID_NDK=/home/daniel/Desktop/programming/android/adt-x86/ndk/
and
cmake -CMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 ..


This is the result and cant get to the bottom of it:
loading initial cache file MAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake
CMake Error: Error processing file:MAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so
-- Looking for XOpenDisplay in /usr/lib/i386-linux-gnu/libX11.so;/usr/lib/i386-linux-gnu/libXext.so - found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Found X11: /usr/lib/i386-linux-gnu/libX11.so
-- Found OpenGL: /usr/lib/i386-linux-gnu/libGL.so
-- Found GLEW: /usr/lib/i386-linux-gnu/libGLEW.so
-- Found JPEG: /usr/lib/i386-linux-gnu/libjpeg.so
-- Found Freetype: /usr/lib/i386-linux-gnu/libfreetype.so
-- Found OpenAL: /usr/lib/i386-linux-gnu/libopenal.so
-- Found SNDFILE: /usr/lib/i386-linux-gnu/libsndfile.so
-- Configuring incomplete, errors occurred!



So not sure what the config error is as it doesnt actually tell me any specific error.....anything I am missing here?
Title: Re: Android and iOS ports available for testing
Post by: Mario on January 03, 2014, 11:23:22 pm
Your command line is wrong. To set a define on the command line you'll have to make sure to start with a "D" (for define):

cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 ..
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on January 04, 2014, 03:17:25 am
inserted the D there and now I have different issues.  I consider myself pretty computer savy but not overly so on Linux so I am trying to track it down as much as possible....but this is what i am getting now

Quote
daniel@ubuntu:~/Desktop/programming/android/SFML/build$ cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 ..
CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/x86-4.6/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/arm-linux-androideabi-clang3.3/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/mipsel-linux-android-4.6/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/x86-clang3.2/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/llvm-3.2/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/arm-linux-androideabi-clang3.2/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/mipsel-linux-android-clang3.3/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/x86-4.8/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/mipsel-linux-android-clang3.2/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/llvm-3.3/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/x86-clang3.3/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Warning at cmake/toolchains/android.toolchain.cmake:326 (message):
  Could not uniquely determine machine name for compiler from
  /home/daniel/Desktop/programming/android/adt-x86/ndk-r9/toolchains/mipsel-linux-android-4.8/prebuilt/linux-x86_64.
Call Stack (most recent call first):
  cmake/toolchains/android.toolchain.cmake:502 (__DETECT_TOOLCHAIN_MACHINE_NAME)
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Error at cmake/toolchains/android.toolchain.cmake:514 (message):
  Could not any working toolchain in the NDK.  Probably your Android NDK is
  broken.
Call Stack (most recent call first):
  /usr/share/cmake-2.8/Modules/CMakeDetermineSystem.cmake:86 (INCLUDE)
  CMakeLists.txt:17 (project)


CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_C_COMPILER
CMake Error: Could not find cmake module file:/home/daniel/Desktop/programming/android/SFML/build/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER_ENV_VAR
CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly.
Missing variable is:
CMAKE_CXX_COMPILER
CMake Error: Could not find cmake module file:/home/daniel/Desktop/programming/android/SFML/build/CMakeFiles/CMakeCXXCompiler.cmake
CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!

I know that is a lot to look at so here is what I figure out about it so far on my own.  All those initial warnings looks like they are looking for the compilers in the NDK directories but for some reason it seems to be looking in a linux-x86_64 directory which wont exist in that location for any of those since I am on an x86 system (actually in WMware Player) and only have the linux-86 directory there because I downloaded the x86 NDK from the Android website.

So it looks like it goes through all the folders i guess looking for a compatible compiler but it cant find one do to the fact that the folder it tries to look in doesnt exist.  And since it cant find one, it is unable to set all the variables at the bottom of that error list.

I know overall the NDK works as I can do a simple project using the ADT and use native code on my own making some OpenGL calls with success.

Anyone have had a similar issue?  I been trying to hack through this most of the day and am about to go back and give it a shot in Windows but am trying to teach myself Linux stuff at the same time so would like to develop in that system to become more familiar with it.





EDIT:
It seems if I run the same command twice consecutively, the second time it looks in the linux-86 directories and gives warning on a few of the directories but seems to find some of the compatible compilers and is therefore able to set those variables and it reports "Configuring done" and "Generating done".

I then try the make -j8 command and get the following
Quote
daniel@ubuntu:~/Desktop/programming/android/SFML/build$ make -j8
Scanning dependencies of target sfml-system
Scanning dependencies of target sfml-activity
Scanning dependencies of target sfml-main
[  1%] Building CXX object src/SFML/Main/CMakeFiles/sfml-activity.dir/SFMLActivity.cpp.o
/home/daniel/Desktop/programming/android/SFML/src/SFML/Main/SFMLActivity.cpp: In function 'void ANativeActivity_onCreate(ANativeActivity*, void*, size_t)':
/home/daniel/Desktop/programming/android/SFML/src/SFML/Main/SFMLActivity.cpp:151:113: warning: invalid conversion from 'void*' to 'void (*)(ANativeActivity*, void*, size_t) {aka void (*)(ANativeActivity*, void*, unsigned int)}' [-fpermissive]
     void (*ANativeActivity_onCreate)(ANativeActivity*, void*, size_t) = dlsym(handle, "ANativeActivity_onCreate");
                                                                                                                 ^
[  2%] Building CXX object src/SFML/Main/CMakeFiles/sfml-main.dir/MainAndroid.cpp.o
[  3%] [  4%] Linking CXX shared library ../../../lib/libsfml-activity.so
[  6%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o
arm-linux-androideabi-g++: error: SONAME_FLAGlibsfml-activity.so: No such file or directory
make[2]: *** [lib/libsfml-activity.so] Error 1
make[1]: *** [src/SFML/Main/CMakeFiles/sfml-activity.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[  7%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Err.cpp.o
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Lock.cpp.o
[  8%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Mutex.cpp.o
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Sleep.cpp.o
[  9%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/String.cpp.o
[ 10%] [ 12%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/ThreadLocal.cpp.o
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Thread.cpp.o
[ 13%] [ 14%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Time.cpp.o
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ClockImpl.cpp.o
[ 15%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/MutexImpl.cpp.o
[ 17%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/SleepImpl.cpp.o
[ 18%] [ 19%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ThreadImpl.cpp.o
[ 20%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Unix/ThreadLocalImpl.cpp.o
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Android/Activity.cpp.o
[ 21%] Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o
Linking CXX static library ../../../lib/libsfml-main.a
[ 21%] Built target sfml-main
Linking CXX shared library ../../../lib/libsfml-system.so
arm-linux-androideabi-g++: error: SONAME_FLAGlibsfml-system.so: No such file or directory
make[2]: *** [lib/libsfml-system.so] Error 1
make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
make: *** [all] Error 2
daniel@ubuntu:~/Desktop/programming/android/SFML/build$

errors in building the actual libraries
Title: Re: Android and iOS ports available for testing
Post by: Mario on January 04, 2014, 11:31:26 am
There's something going wrong. I'd suggest you clear your build directory by hand and try once again. Maybe the first attempts screwed up something. Or did you do that already?
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on January 04, 2014, 06:18:41 pm
yeah i have tried multiple times deleting the entire build directory and starting over from scratch with the same results.
Title: Re: Android and iOS ports available for testing
Post by: Cpl.Bator on January 04, 2014, 06:44:25 pm
Quote
arm-linux-androideabi-g++: error: SONAME_FLAGlibsfml-system.so: No such file or directory

Same problem here.
Title: Re: Android and iOS ports available for testing
Post by: Mario on January 04, 2014, 07:32:00 pm
Can't test is right now,  but looks like a typo in the code (like missing space or something similar).
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on January 05, 2014, 03:33:40 am
it it helps i am using cmake version 2.8.7 from the command line on Ubuntu 12.04
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on January 05, 2014, 08:25:09 am
so it appears i finally got success in using cmake and compiling sfml for android....here is what i found out should others have the same issue.

1 - I was initially using cmake 2.8.7 and was having all of those problems and errors outlined in my first post
2 - I then put some message statements into the cmake toolchain file and realized that it wasnt pulling in the ANDROID_NDK environment variable i was setting from the command line so as far as cmake was concerned the path to the ANDROID_NDK was "".  So I just added that variable on the command line to cmake and was able to cmake successfully
Quote
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 -DANDROID_NDK=/home/daniel/Desktop/programming/android/adt-x86/ndk-r9 ..
3 - but at that point I would then try to do the make but would receive errors in the compilation process due to the SONAME_FLAG issue that was detailed in the other post.  I did some googling and people recommened to update cmake to at least 2.8.9 to fix that issue
4 - So i go to the cmake website and get the latest version of 2.8.12 and installed it
5 - I then went back and deleted my build dir and recreated it empty and ran cmake again.....now cmake would give errors about unable to find certain files and I found that it was putting its version number (2.8.12) into that path of where it expected some of the cmake files inside the SFML drectories
6 - I then went and downgraded to cmake 2.8.9 and started this process over again
7 - this time success with cmake and make to build the libraries
8 - now i did still have to specify the ANDROID_NDK on the command line for cmake as for some reason it wouldnt pick up the environment variable of the same name i would export right before doing the cmake

hopefully anyone else running into this problem then this will help them out

now my next task is figuring out how to get the sfml into my programs.  I have already been doing some NDK stuff on my own with raw OpenGL so I have figured out a little of it.  I also dabbled with SDL2 when I was hitting these brick walls with SFML and successfully got it setup, but I much prefer the c++ interface of SFML so I came back to give it another shot in compiling it and success this time.

If anyone has a step by step process to use SFML in an eclipse project then let me know.
Title: Re: Android and iOS ports available for testing
Post by: Fizix on January 08, 2014, 03:24:20 am
Tried testing on x86 emulator with the following results:

1.  Creating a pbuffer with 0 size (which is the default if no params are specified in the attribs) results in an EGL_BAD_ALLOC error and crashes the app.

2.  I could not get it to load an image successfully.  new priv::ResourceStream(filename); in Image.cpp:134 causes: Fatal signal 11 (SIGSEGV)...

When not trying to load textures, the rest works as expected.

EDIT: Tried the same thing for arm on an actual device (galaxy s4) and get a similar problem.  It gets fatal signal 11 at 0xdeadbaad, so somewhere something uninitialized is used it seems.
Title: Re: Android and iOS ports available for testing
Post by: Fizix on January 09, 2014, 02:41:42 pm
After testing some devices it's clear that the pbuffer problem only happens on some devices.  Creating it with size 1x1 solves it for all devices.

My seg fault problems was due to main creating a temp std::string to call things like Texture::loadFromFile and Music::openFromFile.  I don't know much about these things but it looks like a library linking issue.  Adding a new method that takes a const char* and forwarding it to the std::string version solves the problem 100%.

Also, I'm new here and would like to know if I can log bugs somewhere or send pull requests or anything else to help out.
Title: Re: Android and iOS ports available for testing
Post by: Mario on January 09, 2014, 02:51:55 pm
https://github.com/SFML/SFML/tree/ios_and_android
Title: Re: Android and iOS ports available for testing
Post by: OgreValley on January 10, 2014, 07:30:23 pm
Hi,

Am I the only one getting an error message telling that 'EGL/egl.h file not found', when building for iOS?

I've looked through the whole post, and it doesn't seem that anyone else have the same problem.

I'm running OSX 10.9 Mavericks, iOS 7 on x64 simulator.

/Kenneth
Title: Re: Android and iOS ports available for testing
Post by: PaoloOrange on January 21, 2014, 02:36:59 pm
Hi,

Am I the only one getting an error message telling that 'EGL/egl.h file not found', when building for iOS?

I've looked through the whole post, and it doesn't seem that anyone else have the same problem.

I'm running OSX 10.9 Mavericks, iOS 7 on x64 simulator.

/Kenneth

I have the same issue (and the same system configuration).
Title: Re: Android and iOS ports available for testing
Post by: nero81af on January 27, 2014, 02:02:57 am
hello! I'm new to the forum and I'm doing some testings on ios and android ports in order to make a cross platform framework.

I'm building sfml in my own makefiles and building only window and system modules in libsfml.a on windows using mingw: these are my compilation flags:

DEFS= -DSFML_STATIC -DSFML_OPENGL_ES -D__STDC_FORMAT_MACROS -D__USE_BSD -D_BSD_SOURCE -DPOSIX_SOURCE -DGL_GLEXT_PROTOTYPES -Dfdatasync=fsync -DPIC -fPIC -fexceptions -frtti -std=gnu++11
LDFLAGS = -lGLESv1_CM -lGLESv2 -lstlport_static -lc -ldl -lgcc -landroid -lEGL
CFLAGS = -shared -LC:\android\ndk\sources/cxx-stl/stlport/libs/armeabi-v7a -LC:\android\ndk\platforms/android-17/arch-arm/usr/lib C:\android\ndk\platforms/android-17/arch-arm/usr/lib/crtbegin_static.o -nostdlib -Wl,--no-undefined -Wl,--whole-archive libsfml.a -Wl,--no-whole-archive

everything goes ok in window and linux but once I try android things gets hard: I managed to compile and make an apk but when I run a simple main creating a window and displaying a cube, I get a black screen in emulator. in particular eglCreatePbufferSourface returns egl_bad_alloc. I tried to fix it using some custom attributes list: no more errors but still I get black screen with eglSurfaceAttrib not implemented.

#include <stdio.h>

#include <exception>

#include "rs.hpp"
#ifdef RS_PLATFORM_ANDROID
#include <GLES/gl.h>
#include <GLES/glext.h>
#include <GLES2/gl2.h>
#include <GLES2/gl2ext.h>
#elif RS_PLATFORM_IOS
#include <OpenGLES/ES1/gl.h>
#include <OpenGLES/ES1/glext.h>
#include <OpenGLES/ES2/gl.h>
#include <OpenGLES/ES2/glext.h>
#else
#include "glew/GL/glew.h"
#endif
#include "sfml/SFML/Window.hpp"

#define _PLAYGROUND_NAME    "playground"
#define _PLAYGROUND_VERSION "0.1.0"

using namespace std;

int main(int argc,char **p_argv)
{
        try
        {
                sf::Window window(sf::VideoMode::getDesktopMode(),"OpenGL");
                glEnable(GL_DEPTH_TEST);
                glDepthMask(GL_TRUE);
#ifdef RS_PLATFORM_ANDROID
                glClearColor(1.0,1.0,1.0,1.0);
                glClearDepthf(1.f);
#elif RS_PLATFORM_IOS
                glClearColor(1.0,1.0,1.0,1.0);
                glClearDepthf(1.f);
#else
                glClearDepth(1.f);
#endif
                glDisable(GL_LIGHTING);
                glViewport(0,0,window.getSize().x,window.getSize().y);
                glMatrixMode(GL_PROJECTION);
                glLoadIdentity();
                GLfloat ratio = static_cast<float>(window.getSize().x) / window.getSize().y;
#ifdef RS_PLATFORM_ANDROID
                glFrustumf(-ratio, ratio, -1.f, 1.f, 1.f, 500.f);
#elif RS_PLATFORM_IOS
                glFrustumf(-ratio, ratio, -1.f, 1.f, 1.f, 500.f);
#else
                glFrustum(-ratio, ratio, -1.f, 1.f, 1.f, 500.f);
#endif

                GLfloat cube[] =
                {
                        -20, -20, -20,  0, 0,
                        -20,  20, -20,  1, 0,
                        -20, -20,  20,  0, 1,
                        -20, -20,  20,  0, 1,
                        -20,  20, -20,  1, 0,
                        -20,  20,  20,  1, 1,
                         20, -20, -20,  0, 0,
                         20,  20, -20,  1, 0,
                         20, -20,  20,  0, 1,
                         20, -20,  20,  0, 1,
                         20,  20, -20,  1, 0,
                         20,  20,  20,  1, 1,
                        -20, -20, -20,  0, 0,
                         20, -20, -20,  1, 0,
                        -20, -20,  20,  0, 1,
                        -20, -20,  20,  0, 1,
                         20, -20, -20,  1, 0,
                         20, -20,  20,  1, 1,
                        -20,  20, -20,  0, 0,
                         20,  20, -20,  1, 0,
                        -20,  20,  20,  0, 1,
                        -20,  20,  20,  0, 1,
                         20,  20, -20,  1, 0,
                         20,  20,  20,  1, 1,
                        -20, -20, -20,  0, 0,
                         20, -20, -20,  1, 0,
                        -20,  20, -20,  0, 1,
                        -20,  20, -20,  0, 1,
                         20, -20, -20,  1, 0,
                         20,  20, -20,  1, 1,
                        -20, -20,  20,  0, 0,
                         20, -20,  20,  1, 0,
                        -20,  20,  20,  0, 1,
                        -20,  20,  20,  0, 1,
                         20, -20,  20,  1, 0,
                         20,  20,  20,  1, 1
                };

                glEnableClientState(GL_VERTEX_ARRAY);
                glEnableClientState(GL_TEXTURE_COORD_ARRAY);
                glVertexPointer(3, GL_FLOAT, 5 * sizeof(GLfloat), cube);
                glTexCoordPointer(2, GL_FLOAT, 5 * sizeof(GLfloat), cube + 3);
                glDisableClientState(GL_NORMAL_ARRAY);
                glDisableClientState(GL_COLOR_ARRAY);
                sf::Clock clock;

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

                        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
                        glMatrixMode(GL_MODELVIEW);
                        glLoadIdentity();
                        glTranslatef(0, 0, -100.f);
                        glRotatef(clock.getElapsedTime().asSeconds() * 50.f, 1.f, 0.f, 0.f);
                        glRotatef(clock.getElapsedTime().asSeconds() * 30.f, 0.f, 1.f, 0.f);
                        glRotatef(clock.getElapsedTime().asSeconds() * 90.f, 0.f, 0.f, 1.f);
                        glDrawArrays(GL_TRIANGLES, 0, 36);
                        window.display();
                }
        }
        catch(exception &exception)
        {

        }

        return 0;
}
 
Title: Re: Android and iOS ports available for testing
Post by: Fizix on January 27, 2014, 09:20:26 am
I also got the EGL_BAD_ALLOC, and setting the width and height to 1 in the attribs for creating the pbuffer solved it for me and rendering continued as normal.
Title: Re: Android and iOS ports available for testing
Post by: nero81af on January 27, 2014, 01:10:24 pm
I could manage to display some graphics using the sfml-graphic module: I rendered a blue rectangle on white background on android. so probably the problem is in my opengl setup! dunno where tho
Title: Re: Android and iOS ports available for testing
Post by: nero81af on January 27, 2014, 02:38:49 pm
ok I got it working! it was a problem on my opengl code! still have to figure out what! probably some unimplemented feature of opengl es! btw eglCreatePbufferSourface really need another type of initialization!

Window/EGLContext.cpp: line 86:
- EGLint attrib_list[] = { EGL_NONE };
+ EGLint attrib_list[] = { EGL_WIDTH,1,EGL_HEIGHT,1,EGL_NONE };
Title: Re: Android and iOS ports available for testing
Post by: 93interactive on January 27, 2014, 05:01:58 pm
There's no audio module on iOS, I'm still waiting for libsndfile to add a license exception for iOS so that I can use it statically without breaking the terms of the license. The author said it was one of its priorities, but it was months ago and I've got no news...

Well, great news in general, but do you have any hint that the author will add this exception, because i found a quote of the original developer on stackoverflow where he mentioned that he is quite happy with LGPL and when asked if he could make an exception for someones iOS game, he answered with something similar like 'i could do that but then i would have to track down every developer who has commited something and i won't do that'

So unless you have got some hint from him, that he will do it, i would not count on it.

I personally could live with throwing out libsndfile and just limit audio format support to ogg/vorbis, which is bsd licensed.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on January 27, 2014, 07:26:02 pm
Quote
So unless you have got some hint from him, that he will do it, i would not count on it.
He said it to me personally by e-mail. And it was of course after he wrote that post on stackoverflow. But... it was strange that he changed his mind so quickly, so maybe it was just a way to get rid of me ;D
Title: Re: Android and iOS ports available for testing
Post by: short_name on February 03, 2014, 12:37:52 am
No joy so far.  I can compile the android port without problems and I can run all the samples that come with the NDK on an AVD and on my phone but I cannot run the sample that comes with the android_and_IOS port.  When I try to run it on either an AVD or on my real Nexus 4 it starts and then says "Unfortunately, SFML has stopped."

Building the project seems to work fine. Here is the output from ~/android-ndk-r9/ndk-build:
Code: [Select]
Android NDK: WARNING: APP_PLATFORM android-14 is larger than android:minSdkVersion 9 in ./AndroidManifest.xml   
Gdbserver      : [arm-linux-androideabi-4.6] libs/armeabi-v7a/gdbserver
Gdbsetup       : libs/armeabi-v7a/gdb.setup
Install        : libsfml-activity.so => libs/armeabi-v7a/libsfml-activity.so
Install        : libsfml-example.so => libs/armeabi-v7a/libsfml-example.so
Install        : libsfml-system.so => libs/armeabi-v7a/libsfml-system.so
Install        : libsfml-window.so => libs/armeabi-v7a/libsfml-window.so
Install        : libsfml-graphics.so => libs/armeabi-v7a/libsfml-graphics.so
Install        : libsfml-audio.so => libs/armeabi-v7a/libsfml-audio.so
Install        : libsfml-network.so => libs/armeabi-v7a/libsfml-network.so
Install        : libstlport_shared.so => libs/armeabi-v7a/libstlport_shared.so
Install        : libopenal.so => libs/armeabi-v7a/libopenal.so
Install        : libsndfile.so => libs/armeabi-v7a/libsndfile.so
Here are what I think are the relevant log messages when it crashes:
Code: [Select]
02-02 16:30:52.743: I/ActivityManager(601): Start proc com.example.sfml for activity com.example.sfml/android.app.NativeActivity: pid=22731 uid=10155 gids={50155}
02-02 16:30:52.763: I/SearchController(24544): #onHotwordDetectorStopped
02-02 16:30:52.763: I/MicrophoneInputStream(24544): mic_close
02-02 16:30:52.773: D/dalvikvm(826): GC_CONCURRENT freed 495K, 6% free 9518K/10080K, paused 2ms+1ms, total 15ms
02-02 16:30:52.843: D/dalvikvm(24544): threadid=49: thread exiting, not yet detached (count=0)
02-02 16:30:52.843: D/dalvikvm(24544): threadid=37: thread exiting, not yet detached (count=0)
02-02 16:30:52.893: I/Adreno-EGL(22731): <qeglDrvAPI_eglInitialize:320>: EGL 1.4 QUALCOMM Build: I0404c4692afb8623f95c43aeb6d5e13ed4b30ddbDate: 11/06/13
02-02 16:30:52.914: D/dalvikvm(826): GC_CONCURRENT freed 388K, 6% free 9515K/10080K, paused 1ms+1ms, total 14ms
02-02 16:30:53.084: D/dalvikvm(826): GC_CONCURRENT freed 483K, 6% free 9520K/10080K, paused 2ms+2ms, total 21ms
02-02 16:30:53.444: A/libc(22731): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22748 (om.example.sfml)
02-02 16:30:53.504: I/DEBUG(171): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-02 16:30:53.504: I/DEBUG(171): Build fingerprint: 'google/occam/mako:4.4.2/KOT49H/937116:user/release-keys'
02-02 16:30:53.504: I/DEBUG(171): Revision: '10'
02-02 16:30:53.504: I/DEBUG(171): pid: 22731, tid: 22748, name: om.example.sfml  >>> com.example.sfml <<<
02-02 16:30:53.504: I/DEBUG(171): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
and the backtrace:
Code: [Select]
02-02 16:30:53.654: I/DEBUG(171): backtrace:
02-02 16:30:53.664: I/DEBUG(171):     #00  pc 00000000  <unknown>
02-02 16:30:53.664: I/DEBUG(171):     #01  pc 000417a3  /system/lib/egl/libGLESv2_adreno.so (glGetString+16)
02-02 16:30:53.664: I/DEBUG(171):     #02  pc 0001c909  /system/lib/egl/libGLESv1_CM_adreno.so (Load_Gll_2_0+984)
02-02 16:30:53.664: I/DEBUG(171):     #03  pc 00021d03  /system/lib/egl/libGLESv1_CM_adreno.so (gliMakeCurrent+18)
02-02 16:30:53.664: I/DEBUG(171):     #04  pc 00024d89  /system/lib/egl/libGLESv1_CM_adreno.so (oglSetBuffers+48)
02-02 16:30:53.664: I/DEBUG(171):     #05  pc 0001c7f4  /system/lib/egl/libEGL_adreno.so (eglGLUpdateSurfaces+648)
02-02 16:30:53.664: I/DEBUG(171):     #06  pc 00010b50  /system/lib/egl/libEGL_adreno.so (qeglDrvAPI_eglMakeCurrent+628)
02-02 16:30:53.664: I/DEBUG(171):     #07  pc 00006b0c  /system/lib/egl/libEGL_adreno.so (eglMakeCurrent+16)
02-02 16:30:53.664: I/DEBUG(171):     #08  pc 0000d3e5  /system/lib/libEGL.so (android::egl_display_t::makeCurrent(android::egl_context_t*, android::egl_context_t*, void*, void*, void*, void*, void*, void*)+84)
I have tried it using API Level 17, 18 and 19 on AVD's. 
I am using ndk-r9 per the post by sonkun at November 29, 2013, 05:18:00 PM
I believe I configured cmake properly, but I attached a screenshot of my cmake-gui configuration.
Title: Re: Android and iOS ports available for testing
Post by: Xotraz on February 05, 2014, 04:10:39 pm
Hi, when i wanted to use my makefies, i had some errors to compile SFML for Android.

C:\Users\TRS>cmake --build C:/Users/TRS/Desktop/Création/SFML-Android-Build
CMake Error: Target DependInfo.cmake file not foundScanning dependencies of targ
et sfml-system

CMake Error: Directory Information file not found
Building CXX object src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o
G__~1.EXE: error: unrecognized command line option '-mfloat-abi=softfp'
G__~1.EXE: error: unrecognized command line option '-mfpu=vfpv3-d16'
G__~1.EXE: error: unrecognized command line option '-mthumb'
G__~1.EXE: error: C:\Users\TRS\Desktop\Cr&#9484;ation\SFML-Android\src\SFML\System\Clo
ck.cpp: No such file or directory
G__~1.EXE: fatal error: no input files
compilation terminated.
make.exe[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Clock.cpp.o] Error
1
make.exe[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
make.exe: *** [all] Error 2

C_Make_SH was not found (and i dont know where is his directory).

Thank for any help, i dont know what i must do.
I use MinGW makesfiles.

EDIT : This work only without special character like é.
Title: Re: Android and iOS ports available for testing
Post by: xuanzon on February 10, 2014, 11:11:13 am
Hi, i just test on my android device with...

build environment : windows 7 x64

build toolchain : android SDK & NDK x64

test device : sony xperia s lt26i

instructions: cmake -G "MinGW Makefiles" -DANDROID_ABI=armeabi-v7a -DANDROID_NATIVE_API_LEVEL=9 -DANDROID_USE_STLPORT=TRUE -DCMAKE_TOOLCHAIN_FILE=D:\git\sfml\cmake\toolchains\android.toolchain.cmake -DCMAKE_MAKE_PROGRAM=c:\android\android-ndk-r9c\prebuilt\windows-x86_64\bin\make.exe ..\sfml

run result : an sfml icon black screen, then a white screen with birds sound.

I am new here, so i don't know the result is correct? :-[
Title: Re: Android and iOS ports available for testing
Post by: Xotraz on February 10, 2014, 04:56:49 pm
No but i have exactly the same issue.

Ican use the program with a white screen and song.
In the logchat :
E/libEGL(930): called unimplemented OpenGL ES API

And when i use OpenGLES emulation :
failed to create/resize pbuffer
at start and it just crash.

I think Android wanted to use 2.0 OGL and SFML wanted to use 1.0 but didnt find how to solve this problem.
And i must check OpenGLES emulation.
Title: Re: Android and iOS ports available for testing
Post by: nero81af on February 12, 2014, 02:48:21 pm
try this patch

Window/EGLContext.cpp: line 86:
- EGLint attrib_list[] = { EGL_NONE };
+ EGLint attrib_list[] = { EGL_WIDTH,1,EGL_HEIGHT,1,EGL_NONE };
Title: Re: Android and iOS ports available for testing
Post by: Xotraz on February 13, 2014, 06:20:21 pm
Thank you for this tips, but this change nothing for me  :-\
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on February 13, 2014, 07:46:09 pm
Hi,

It's been quite a long time since I last answered here because I was busy with other stuff. I'll be back next  week to carry on working on the Android port and answer your technical questions. :)
Title: Re: Android and iOS ports available for testing
Post by: Dethska on February 14, 2014, 10:04:16 pm
try this patch

Window/EGLContext.cpp: line 86:
- EGLint attrib_list[] = { EGL_NONE };
+ EGLint attrib_list[] = { EGL_WIDTH,1,EGL_HEIGHT,1,EGL_NONE };

This was the key for me to get the example project working.  Thanks!
Title: Re: Android and iOS ports available for testing
Post by: Grimshaw on February 22, 2014, 02:36:41 pm
One question. Is the audio working perfectly in IoS?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on February 22, 2014, 07:19:46 pm
There's no audio on iOS. I'm still waiting for libsndfile :-\
Title: Re: Android and iOS ports available for testing
Post by: Grimshaw on February 22, 2014, 07:58:49 pm
What a drag...

Anyway, all I ever need(most likely) is .ogg, guess i'll write a decoder just for it or something :x I think I shouldn't get my hopes high waiting for them right? :p
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on February 24, 2014, 01:43:11 pm
You are no longer forced to use "sfml-example" as library name for your application. The SFML activity now reads the manifest file which comes along with your Android project in order to retrieve it, thus you need to add the following line to AndroidManifest.xml:

<meta-data android:name="sfml.app.lib_name" android:value="myCustomLibraryName" />

If you forget it, an error saying "No meta-data 'sfml.app.lib_name' found in AndroidManifest.xml file" will appear.

By the way, I'm still working on the gnustl support to enable C++11 features in your applications. :)
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on February 25, 2014, 06:09:18 pm
Aye! :D Just found out what goes wrong when using the GNU implementation of STL! I'll drop stlport in favor of gnustl shortly so we can enable C++11 in our app! I hope it will also fix SFML not working on some Android device by the way...

Tomorrow, I'll fix the transparency issue properly so you won't have to modify GlExtensions.hpp manually anymore. :)
Title: Re: Android and iOS ports available for testing
Post by: Mario on February 27, 2014, 12:18:19 pm
Does that include crashes on Nexus 5? Sounds interesting. :)
Title: Re: Android and iOS ports available for testing
Post by: nero81af on February 28, 2014, 12:42:03 pm
I've finally menaged to build ogre over sfml and cegui over ogre on windows mac Linux android and iOS! now I have one last problem with android! when I show the keyboard with

sf::Keyboard::setVirtualKeyboardVisible(true)

I can see the virtual keyboard but I can't capture inputs!

I tried to investigate in the method

int WindowImplAndroid::processEvent(int fd, int events, void* data)

that is attached to a looper in

static void onInputQueueCreated(ANativeActivity* activity, AInputQueue* queue)

but when I try to press a key processEvent callback is not entered! the only keys that works are tab and backspace!
Title: Re: Android and iOS ports available for testing
Post by: nero81af on February 28, 2014, 04:01:44 pm
little update: I updated android and now processEvent get called but I still cannot have input since getUnicode() in

void WindowImplAndroid::processKeyEvent(AInputEvent* _event, ActivityStates* states)

always returns 0!
Title: Re: Android and iOS ports available for testing
Post by: nero81af on March 05, 2014, 04:50:38 pm
I'd like to signal the bug I've found on Android! It's quite important since otherwise the app will crash sooner or later:

in WindowImplAndroid.cpp

301 + lJavaVM->DetachCurrentThread();

504 - case AKEYCODE_DEL: return Keyboard::Delete;
504 + case AKEYCODE_DEL : return Keyboard::BackSpace;

593 - jobject ObjectKeyEvent = lJNIEnv->NewObject(ClassKeyEvent, KeyEventConstructor, (jvalue*)downTime, (jvalue*)eventTime, (jvalue*)action, (jvalue*)code, (jvalue*)repeat, (jvalue*)metaState, (jvalue*)deviceId, (jvalue*)scancode, (jvalue*)flags, (jvalue*)source);
593 + jobject ObjectKeyEvent = lJNIEnv->NewObject(ClassKeyEvent, KeyEventConstructor, downTime, eventTime, action, code, repeat, metaState, deviceId, scancode, flags, source);

602 + lJavaVM->DetachCurrentThread();
Title: Re: Android and iOS ports available for testing
Post by: johnjoemcbob on March 07, 2014, 05:47:52 pm
Hi,
I'm running 64bit Windows 8 and am having trouble with the initial setup.

I've managed to get the basic native-activity sample from android built using the command line, but am having difficulty setting up SFML for Android.

I've never used cmake before now so I'm not sure if I was doing it right, but I'll run you through the steps I took.

1. Downloaded the android-ndk
(Placed in C:/NVPACK/android-ndk)

2. Cloned the repo, and switched to the ios & android branch
(Placed in C:\Users\Matthew\Documents\GitHub\SFML)

3. Downloaded cmake 2.8.12.2 and ran the cmake-gui
3.1. Set source as C:/Users/Matthew/Documents/GitHub/SFML
3.2. Set destination as C:/Users/Matthew/Desktop/AndroidSMFL
3.3. Clicked configure
3.4. Specified generator as Visual Studio 10 with custom toolchain file for cross-compiling
(Toolchain at C:/Users/Matthew/Documents/GitHub/SFML/cmake/toolchains/android.toolchain.cmake)
3.5. Finish
3.6. (Receive error Could not find neither Android NDK nor Android standalone toolcahin.)
(Must specify ANDROID_NDK)
3.7. Added entry ANDROID_NDK as FILEPATH; C:/NVPACK/android-ndk
3.8. Ticked ANDROID_USE_STLPORT
http://i.imgur.com/Kq8hJaU.png (http://i.imgur.com/Kq8hJaU.png)

3.9. Clicked configure again
http://i.imgur.com/RPG1Giq.png (http://i.imgur.com/RPG1Giq.png)

3.10. Clicked generate (no errors)
Contents of build location;
http://i.imgur.com/f86JLsy.png (http://i.imgur.com/f86JLsy.png)

4. Downloaded cygwin64 with make
(Placed in C:/cygwin64)
4.1. Ran the following command;
C:/cygwin64/bin/make C:/Users/Matthew/Desktop/AndroidSFML
Failed
http://i.imgur.com/bAJRTlV.png (http://i.imgur.com/bAJRTlV.png)

4.2. Ran the following command;
C:/cygwin64/bin/make install C:/Users/Matthew/Desktop/AndroidSFML
Failed

5. Instead opened the C:/Users/Matthew/Desktop/AndroidSFML/SFML.sln using Visual Studios 10 Express
5.1. Right clicked on the INSTALL project and clicked Build
Failed
Build log - http://pastebin.com/raw.php?i=qMRXSXAt

5.2. C:\NVPACK\android-ndk\sources\sfml after INSTALL build was as follows;
http://i.imgur.com/AAru0cn.png (http://i.imgur.com/AAru0cn.png)

(Images were large so I left them as links)

As I said I don't have much experience with cmake or the like, so any help would be greatly appreciated

Thanks,
Matthew
Title: Re: Android and iOS ports available for testing
Post by: Mario on March 07, 2014, 06:41:05 pm
First, uninstall Cygwin, unless you need it for something else. The tools in the cygwin package most likely won't like classic Windows path or they'll just pass the wrong paths (i.e. Cygwin paths).

First, install MinGW:
Title: Re: Android and iOS ports available for testing
Post by: johnjoemcbob on March 07, 2014, 09:53:06 pm
Thanks, this helps a lot.
However I now have problems during the make install process,

I used the cmake-gui and had CMAKE_MAKE_PROGRAM set as C:/MinGW/bin/g++.exe

(Built it to C:/Users/Matthew/Desktop/AndroidSFML using the gui)
Then when I ran 'make install' in the directory this happened;
http://pastebin.com/raw.php?i=t4ErTTLN (http://pastebin.com/raw.php?i=t4ErTTLN)

Edit:
Changed STLPORT to disabled and it compiles but then crashes with no errors as Sonkun said it would

(Only crashes when trying to load in assets, otherwise runs fine.)
Title: Re: Android and iOS ports available for testing
Post by: LittleCodingFox on March 10, 2014, 04:53:04 pm
I'd just like to report a bug with the onContentChange method on MainAndroid.cpp

Around lines 318-319:

event.size.width = ANativeWindow_getWidth(states->window);
event.size.height = ANativeWindow_getHeight(states->window);

You're getting the size incorrectly. In certain devices, such as Amazon's Kindle Fire, the window is moved up and resized by the action bar, causing it to e.g., change the size from 1024 height to 1004 height. In this case, however, ANativeWindow will get the old value (1024) while the Rect parameter passed to onContentChange has the right value (1004).

I replaced these lines with the following:

event.size.width = rect->right;
event.size.height = rect->bottom;
Title: Re: Android and iOS ports available for testing
Post by: slotdev on March 11, 2014, 02:41:30 pm
Which version of the Android NDK should I be using for this? r9d, and (I assume) 64 bit given I'm on a 64 bit Windows 7 system. I have VS2010 too.
Title: Re: Android and iOS ports available for testing
Post by: Mario on March 11, 2014, 04:10:42 pm
Any release 9 should be fine. The current instabilities/crashes aren't directly related to the NDK as such (e.g. on the Nexus 5 context creation crashes with the given/default parameters).
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on March 11, 2014, 06:15:20 pm
Hi guys!

Sorry I'm so late in answering you. Finally, it turned out I hadn't fixed the problem and I was still getting weird errors at random places. Actually, I spent the entire last week trying to make SFML work with the GNU version of STL. I just tried everything but it was unsuccessful :( That's why I'm quite delayed here.

Hopefully, yesterday I noticed a new NDK version has been released in the meantime and this one contains a new STL version (the one used by Clang compiler). Thus I dropped everything, GNUSTL (can't make it work, license constraint) and STLPORT (poor C++11 support, upstream development is dead), in favour of this one which has high c++11 support and no license constraint. It seems they're willing to retire the other STL versions as well. Well, I could make SFML work with this version of STL and I'm happy to announce you can now use C++11 in your application and distribute them freely. :)

I will still annoies you with the Android CMake toolchain because it needs to be rewritten to remove features that SFML don't need and which are hard to maintain. Using this new implementation of STL requires the latest NDK version because earlier versions don't have it. However I'll keep the same interface, you just won't need to enable ANDROID_USE_STLPORT but I might introduce new bugs :s.

The good news is SFML now works on some of my devices where it used not to work. What about yours ?

@LittleCodingFox and @nero81af: Thank you very much for reporting bugs. I'll check them as soon as possible!
Title: Re: Android and iOS ports available for testing
Post by: Mario on March 11, 2014, 06:20:16 pm
Is it checked in already? Have to have a look. :)

As for my Nexus 5, the context creation with 1x1 pixels fixed the startup crash. Not sure about other devices though.

Edit:
Fixed some tidbits (pull request incoming right now). Compiles fine for me, although this version OpenAl crashes on my Nexus 5. It compiles and runs fine if I don't use the Audio module.
Title: Re: Android and iOS ports available for testing
Post by: ncsu121978 on March 14, 2014, 07:37:17 am
on Android, how to detect if the player presses the back button or the menu button?  the Home button is really handled by the OS itself and suspends your app, but in other games the back button can be used for menu navigation among other things.  I cant find the way to detect that event.
Title: Re: Android and iOS ports available for testing
Post by: Mario on March 14, 2014, 10:10:03 am
As far as I know buttons (hardware and virtual) aren't implemented yet and get just dropped. E.g. you can't use volume control while an SFML app is active.
Title: Re: Android and iOS ports available for testing
Post by: myl on March 14, 2014, 02:44:24 pm
Hi,

Am I the only one getting an error message telling that 'EGL/egl.h file not found', when building for iOS?

I've looked through the whole post, and it doesn't seem that anyone else have the same problem.

I'm running OSX 10.9 Mavericks, iOS 7 on x64 simulator.

/Kenneth

I have the same issue (and the same system configuration).

I also have this issue on the same system configuration.
Title: Re: Android and iOS ports available for testing
Post by: leafdj on March 23, 2014, 03:10:04 am
Hi all! I'm running into the issue where the app crashes right off the bat without any errors. Both on a Nexus 4 emulator and on a Nexus S device. I believe it has to do with not launching the native activity.

I'm using the r9d release of the ndk, with the latest version of the ios_and_android branch, but I still tried building it with and without -DANDROID_USE_STLPORT=TRUE after I couldn't get it working the first time.
I believe it has to do with not launching the proper activity at the beginning, because I didn't see any similar errors with the ndk native activity example.

Is there a way for me to diagnose if it's something wrong with my SFML build or with my project settings?

--Additional Information--
Using Android Studio on Windows 8 64bit
I built SFML with 'cmake -G "MinGW Makefiles" -DANDROID_NDK=C:/android-ndk-r9d -DCMAKE_TOOLCHAIN_FILE=cmake/toolchains/android.toolchain.cmake'
'make install'

I'm using Android Studio, but have the project set up the same way as the native activity example, so I don't believe that is the problem.

I also included my Android Manifest file, thinking it might simply be a problem in there. It's slightly modified from the sfml example. The important part to note is that android.app.lib.name corresponds to libsfml-activity.so, and sfml.app.lib_name corresponds to libapp.so, which are both in libs/armeabi/.
Title: Re: Android and iOS ports available for testing
Post by: Mario on March 23, 2014, 07:29:59 am
Try disabling all parts of the code related to the Audio module. As far as I know it seems to be some incompatibility with the precompiled OpenAL library.
Title: Re: Android and iOS ports available for testing
Post by: leafdj on March 24, 2014, 02:12:44 am
Thank you! Looks like that was it, in addition, I'm now seeing relevant messages in my logcat console as well, so it should be easier to debug problems now.
I had actually tried removing them all before, but sfml-activity would error out if I didn't include the audio and network shared libraries in the apk.

Just in case it's helpful, this is the logcat error when attempting to play the audio in the example app:
03-23 18:07:25.097    8680-8697/com.leafdj.app A/libc﹕ Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 8697 (.leafdj.app)
Title: Re: Android and iOS ports available for testing
Post by: myl on April 07, 2014, 11:40:28 am
Hi,

Am I the only one getting an error message telling that 'EGL/egl.h file not found', when building for iOS?

I've looked through the whole post, and it doesn't seem that anyone else have the same problem.

I'm running OSX 10.9 Mavericks, iOS 7 on x64 simulator.

/Kenneth

I have the same issue (and the same system configuration).

I also have this issue on the same system configuration.

It seems building for iOS is broken at this point. But I successfully build https://github.com/SFML/SFML/tree/7ba4458bea396434eb29b0e1cc19fe0104747d1c

myl
Title: Re: Android and iOS ports available for testing
Post by: Laurent on April 07, 2014, 12:29:23 pm
I've identified the problem, it should be fixed soon.

Thanks for the feedback.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on April 07, 2014, 11:31:10 pm
Quote
I've identified the problem, it should be fixed soon.
Done. The EGL stuff should no longer cause errors on iOS.

I've also reviewed the sensor API, it's not tested yet on iOS and has to be rewritten on Android (should be done quickly).
Title: Re: Android and iOS ports available for testing
Post by: Ixrec on April 07, 2014, 11:47:00 pm
Regarding the iOS audio issue, since there's no sign of a licensing breakthrough from libsndfile, how hard would it be to reimplement that part of the module using some other library, like the AVAudioPlayer class that the iOS SDK comes with?  (I don't care about the exact range of file formats we get, as long as it's better than just .wav)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on April 08, 2014, 08:02:37 am
It would require a major internal redesign.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 11, 2014, 03:50:30 pm
Should the Android example to work now? I built it with armeabi-v7a and it crashes on start.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 11, 2014, 04:03:06 pm
Try commenting out all SFML Audio related lines and it should run just fine. It's the precompiled library that somehow screws up.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 11, 2014, 04:08:37 pm
Yes, thank you, it works now. Cool! =)
So i need to build audio libs myself?
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 11, 2014, 04:13:12 pm
It might help, haven't tried it so far, since compiling OpenAL for Android doesn't seem to be too trivial to do. :(
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 11, 2014, 04:20:44 pm
As i remember that task was in my practice a year ago. It was part of an engine of one software company which hired me to outsourcing. I forgot everything, but it was pretty simple. Or it was not OpenAL? =) I need to learn all stuff from the very begining...

Yes, i even found MK from it:
LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := openal
LOCAL_SRC_FILES :=             \
        OpenAL32/alAuxEffectSlot.c \
        OpenAL32/alBuffer.c        \
        OpenAL32/alDatabuffer.c    \
        OpenAL32/alEffect.c        \
        OpenAL32/alError.c         \
        OpenAL32/alExtension.c     \
        OpenAL32/alFilter.c        \
        OpenAL32/alListener.c      \
        OpenAL32/alSource.c        \
        OpenAL32/alState.c         \
        OpenAL32/alThunk.c         \
        Alc/ALc.c                  \
        Alc/alcConfig.c            \
        Alc/alcEcho.c              \
        Alc/alcModulator.c         \
        Alc/alcReverb.c            \
        Alc/alcRing.c              \
        Alc/alcThread.c            \
        Alc/ALu.c                  \
        Alc/android.c              \
        Alc/bs2b.c                 \
        Alc/null.c
LOCAL_C_INCLUDES := $(LOCAL_PATH)/include $(LOCAL_PATH)/OpenAL32/Include
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include/AL
LOCAL_CFLAGS := -DAL_BUILD_LIBRARY -DAL_ALEXT_PROTOTYPES
LOCAL_LDLIBS := -llog -Wl,-s
include $(BUILD_SHARED_LIBRARY)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 11, 2014, 09:02:42 pm
Yep, building of latest OpenAL from repo is not so simple. At the current moment i'm stuck with two things: 1) tons of multiple definitions, 2) i don't know why am i doing it. =)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 13, 2014, 05:50:33 pm
sfml-activity.so and all others are in APK file, but error on start:
Code: [Select]
04-13 19:48:45.121    4368-4368/com.familyxoft.croger E/AndroidRuntime﹕ FATAL EXCEPTION: main
    java.lang.RuntimeException: Unable to start activity ComponentInfo{com.familyxoft.croger/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to find native library: sfml-activity
Any ideas?
upd: No info about libraries in META-INF files.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 14, 2014, 12:20:51 am
Make sure you've got the proper module name set for the native ability. Right now it's still looking for "sfml-activity" rather than whatever you've defined.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 14, 2014, 08:10:19 am
I'm not sure about build.gradle, no, i'm sure that my build.gradle is incorrect. Google changed project's structure in Android Studio again! So, this question is not for this topic, it's for Google. Is there full AS documentation anywhere?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 14, 2014, 05:13:08 pm
Well, in Eclipse all builds perfectly. Another question, how to buld SFMLES with gnustl_static?
And second question, if i build my engine part as shared library, what is right way to call "loadLibrary" for it from game's shared object?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 09:04:10 am
Code: [Select]
04-15 11:00:41.925: D/jdwp(8769): sendBufferedRequest : len=0x45
04-15 11:00:41.928: W/asset(8769): AssetManager-->addDefaultAssets CIP path not exsit!
04-15 11:00:42.487: D/libEGL(8769): loaded /system/lib/egl/libEGL_mali.so
04-15 11:00:42.496: D/libEGL(8769): loaded /system/lib/egl/libGLESv1_CM_mali.so
04-15 11:00:42.499: D/libEGL(8769): loaded /system/lib/egl/libGLESv2_mali.so
04-15 11:00:42.543: V/PhoneWindow(8769): DecorView setVisiblity: visibility = 4
04-15 11:00:42.581: V/PhoneWindow(8769): DecorView setVisiblity: visibility = 0
04-15 11:00:43.049: A/libc(8769): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 8813 (milyxoft.croger)
Program built, apk contains all libs and meta-info, on start crash with this output. What can this be? Now i'll try to build all my code  with debug enabled.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 12:33:28 pm
In deubg build SFMLES eglCheckError is undefined reference.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on April 15, 2014, 12:57:19 pm
Quote
In deubg build SFMLES eglCheckError is undefined reference.
It shouldn't. Make a clean build to be sure ;)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 01:43:31 pm
Well, may be, i'm mixing with SFML and SFMLES, so i can't be sure absolutly. sf::String, for example, i copied from main branch.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 15, 2014, 01:45:09 pm
You shouldn't have to do any modifications on your own, just grab the ios_and_android branch off SFML's main repostiory on GitHub. You might just have to skip SFML audio for now.
Title: Re: Android and iOS ports available for testing
Post by: eXpl0it3r on April 15, 2014, 01:52:12 pm
Getting familiar with the compilation process of native Android application isn’t an easy task so, don’t give up and read carefully the NDK documentation. Maybe you should start with compiling an official example such as NativeActivty located in your NDK. You’ll need to get through this because you won’t be able to reuse this CMake toolchain script to compile your own application (unless your application is a library :D).
Since I don't have the time, to search and teach me all the things around Android and NDK and yet, still would like to test the Android port, is there an easy and at best step by step guide for this?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 01:55:28 pm
You shouldn't have to do any modifications on your own, just grab the ios_and_android branch off SFML's main repostiory on GitHub. You might just have to skip SFML audio for now.
There was some trouble with String. I'll check now, where i went wrong.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 02:26:17 pm
Here it is:
error: 'class sf::String' has no member named 'toUtf8'
Title: Re: Android and iOS ports available for testing
Post by: Nexus on April 15, 2014, 02:40:12 pm
sf::String::toUtf8() was added after SFML 2.1, and it seems not to be part of the ios_and_android branch yet.

By the way, ChronicRat, please use the Edit function if you're adding information to a previous post. Earlier you posted 3 posts and 4 posts in a row; it really makes the thread unnecessarily long and more difficult to read. Users are also notified if you edit the post.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 15, 2014, 04:18:10 pm
I just rebased ios_and_android branch onto master thus to update your local branch git pull won't work, you'll need to recreate it.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 15, 2014, 04:52:32 pm
Just pulled repo. Error in building armeabi-v7a.
/development/sfmles/src/SFML/Window/JoystickManager.cpp: In member function 'void sf::priv::JoystickManager::update()':
/development/sfmles/src/SFML/Window/JoystickManager.cpp:94:57: error: 'class sf::priv::JoystickImpl' has no member named 'getIdentification'
                     item.identification = item.joystick.getIdentification();
                                                         ^
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/JoystickManager.cpp.o] Error 1
 

But i don't understand this: Don't mix stl libs. =)
./../..//src/core/extendedwindow.cpp:101: error: undefined reference to 'sf::String::String(std::string const&, std::locale const&)'
./../..//src/core/log.cpp:212: error: undefined reference to 'sf::String::String(char const*, std::locale const&)'
/home/steelrat/development/android-ndk/sources/oolua/include/oolua/proxy_constructor.h:191: error: undefined reference to 'sf::String::String(std::string const&, std::locale const&)'
/home/steelrat/development/android-ndk/sources/oolua/include/oolua/proxy_caller.h:156: error: undefined reference to 'sf::String::toAnsiString(std::locale const&) const'
./../..//src/gfx/debuginfo.cpp:77: error: undefined reference to 'sf::String::String(char const*, std::locale const&)'
collect2: error: ld returned 1 exit status
 


It's alive:
04-16 10:51:46.153: I/Croger(15876): Using app data dir: /data/croger/
04-16 10:51:46.153: I/Croger(15876): Log file: /data/croger/croger.log
04-16 10:51:46.182: I/Croger(15876): LanguageManager: current locale is (null)
04-16 10:51:46.182: A/libc(15876): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 15902 (milyxoft.croger)
No questions to SFMLES now. =)

As i understand, there is no way to get locale from C. So i think, such method must be implemented in SFMLES. Or may be better is to create some sort of wrapper to allow programer fast bind to java... Well, it is just variant, i have not thought through this.
And AAssetManager must be available with SFML methods.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 16, 2014, 01:13:04 pm
Android example:
04-16 15:06:30.044: A/libc(25459): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 25564 (om.example.sfml)
 
Yes, i can turn off music in example, but i can't turn off music in my game. So this bug is critical, i will try to resolve it myself if Sonkun is busy. And another bug - program crashes or hang ups when rotating phone i.e. crash on screen rotation. Is it tries to recreate window?
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 16, 2014, 01:35:05 pm
Of course that's no permanent solution, just a temporary workaround for testing.

Edit:
As for the build error, you can use this commit:
https://github.com/MarioLiebisch/SFML/commit/b8c2cdcfbc10d76db7cdb2a9f5fa0c544b497ad6

Edit 2:
Why no locale in C? Never tried using setlocale() on Android, but it should be available.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 16, 2014, 03:39:03 pm
Yes, Joystick i fixed already, but i did not declared class member, just return Joystick::Identification();
setlocale returns nullptr. Google said that there is no access to current locale from NDK.
And i built the most fresh OpenAL from repo - no crash on sound play now. I'm just replaced shared object (openal.so) in $(NDK)/sources/sfml/ext-libs and rebuilt Android example - sound works.

First run: broken graphics and no reaction on touch. i'm not implemented using of sf::Touch yet.
Log:
E/libEGL(27480): called unimplemented OpenGL ES API

Title: Re: Android and iOS ports available for testing
Post by: Mario on April 16, 2014, 04:15:14 pm
Interesting. Which OpenAL repository?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 16, 2014, 04:17:27 pm
I thought there is only one. =) This one - http://kcat.strangesoft.net/openal.html
Here is Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)
LOCAL_MODULE := openal

FILE_LIST := $(wildcard $(LOCAL_PATH)/OpenAL32/*.c)
FILE_LIST += $(wildcard $(LOCAL_PATH)/Alc/*.c)
#FILE_LIST += $(wildcard $(LOCAL_PATH)/Alc/backends/*.c)
FILE_LIST += $(wildcard $(LOCAL_PATH)/Alc/effects/*.c)
FILE_LIST += $(wildcard $(LOCAL_PATH)/Alc/midi/*.c)

exclude := %alsa.c %dsound.c %oss.c %portaudio.c %pulseaudio.c\
        %solaris.c %winmm.c %mixer_neon.c %mixer_sse.c %coreaudio.c\
        %mmdevapi.c %qsa.c %sndio.c %mixer_inc.c

FILE_LIST := $(filter-out $(exclude),$(FILE_LIST))

LOCAL_SRC_FILES := $(FILE_LIST:$(LOCAL_PATH)/%=%) Alc/backends/base.c\
        Alc/backends/opensl.c Alc/backends/loopback.c Alc/backends/null.c

LOCAL_C_INCLUDES := $(LOCAL_PATH)/include $(LOCAL_PATH)/OpenAL32/Include $(LOCAL_PATH)/Alc
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include/AL
LOCAL_CFLAGS := -DAL_BUILD_LIBRARY -DAL_ALEXT_PROTOTYPES -DIN_IDE_PARSER -DNO_LOGGING -std=c99
LOCAL_LDLIBS := -lOpenSLES -llog -s
include $(BUILD_SHARED_LIBRARY)
 
About defines:
-std=c99 - solved the problem with multiple definitions.
IN_IDE_PARSER - fixes bug with restrict macro, which is defined only when defined IN_IDE_PARSER
NO_LOGGING - my own define to disable ERR, WARN etc macros. I changed alMain.h:870 a little:
(i'm not checked, may be with forced C99 there are no need to disable log macros)
#ifdef NO_LOGGING
#define TRACEREF(...)
#define TRACE(...)
#define WARN(...)
#define ERR(...)
#else
#define TRACEREF(...) do {                                                    \
    if(LogLevel >= LogRef)                                                    \
        AL_PRINT("(--)", __VA_ARGS__);                                        \
} while(0)


#define TRACE(...) do {                                                       \
    if(LogLevel >= LogTrace)                                                  \
        AL_PRINT("(II)", __VA_ARGS__);                                        \
} while(0)


#define WARN(...) do {                                                        \
    if(LogLevel >= LogWarning)                                                \
        AL_PRINT("(WW)", __VA_ARGS__);                                        \
} while(0)


#define ERR(...) do {                                                         \
    if(LogLevel >= LogError)                                                  \
        AL_PRINT("(EE)", __VA_ARGS__);                                        \
} while(0)

#end
#endif

And you'll need to create own config.h from config.h.in
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 16, 2014, 08:22:11 pm
What exactly this error does mean?
 E/libEGL(3472): called unimplemented OpenGL ES API
I don't use any direct OpenGL code, all operations via SFML.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 16, 2014, 09:35:54 pm
I'd say you (or SFML :P) tried to use some OpenGL ES call that isn't implemented in your version of the NDK for whatever reason.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 17, 2014, 08:05:43 am
Latest NDK, APP_PLATFORM - 10. Test smartphone with Android 4.2.2. What SFMLES need as minimum platform?
And again, what do with shaders? Currently i'm not using shaders, but, in future, may be i can enable GLES2 myself and use own code? Or shaders soon will be in SFMLES?
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 17, 2014, 07:21:51 pm
Never had OpenGL ES issues using APP_PLATFORM on 9. Weird. Would you mind sharing your config.h? Couldn't get it to compile so far.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 17, 2014, 08:29:35 pm
Openal-soft config.h
By the way, may be -DIN_IDE_PARSER in Android.mk is useless too after adding -std=c99
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 18, 2014, 02:53:54 pm
So, i have several thoughts what i need (and i think others too):
1) access to ANativeActivity to get app path, or asset manager, or make it possible via special Android-only interface.
2) callbacks to Android events (Pause, Start) or make them via SFML events system (for example GainedFocus and LostFocus)
3) bind AKEYCODE_BACK to Keyboard::Escape
4) emulate CTRL+ESC (or any other combination, may be dynamicly changable) for AKEYCODE_MENU

Sorry, if all of this is available now, and just i have to rtfm.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 18, 2014, 03:18:57 pm
Got it working late last night. I've had to use the latest source from their repostirry (OpenAL) and make some minor modifications, but it's working and it's quite small as well. :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 19, 2014, 07:05:29 pm
Mario, is sf::VertexArray supported by SFMLES? In my game does not work VertexArrays, Fonts, RenderTextures and sprites has no transparence.  :o
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 19, 2014, 08:00:41 pm
sf::VertexArray should work, I've been using it myself. You just can't use Quads. Is it possible that you're using them?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 19, 2014, 08:21:06 pm
No, i'm using all sorts of Triangles.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 20, 2014, 10:23:02 am
I tested sf::Font in  "example" - it does not work, i don't know why yet. Transparency in test sprite does not work too. Just clear window with non-white color - it is immediately obvious.

    loadLibrary("sfml-system", lJNIEnv, ObjectActivityInfo);
    loadLibrary("sfml-window", lJNIEnv, ObjectActivityInfo);
    loadLibrary("sfml-graphics", lJNIEnv, ObjectActivityInfo);
    loadLibrary("sfml-audio", lJNIEnv, ObjectActivityInfo);
    loadLibrary("sfml-network", lJNIEnv, ObjectActivityInfo);
In debug build this code is incorrect.

Retrived sf::Err() output:
sf::Quads primitive type is not supported on OpenGL ES platforms, drawing skipped
Indeed, Mario, somewhere i'm using quads. But this is only part of render problems.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 20, 2014, 04:09:58 pm
Yes, fonts are broken for me as well.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 20, 2014, 04:48:54 pm
Fonts and transparency, Mario! No transparency everywhere, in all gfx objects.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 20, 2014, 04:52:13 pm
Ah, didn't use transparency so far. That might actually be the same issue then (didn't check whether it's glyph rendering to textures or the rendering to screen). At least glyph dimensions are correct.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 20, 2014, 06:27:51 pm
I fixed sf::Font.

For the transparency issue, in file src/SFML/Graphics/GLExtensions.hpp line 37, you can replace "GL_OES_blend_func_separate" with "false". It shoudl fix your issue. I don't know yet the proper fix.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 20, 2014, 07:29:05 pm
Thanks, now it's much better:
(http://cs616521.vk.me/v616521616/9f62/LWZDxwJ68bE.jpg)

Now i have two questions: what to do with notification zone? Iit eats part of screen, where i have buttons. How to react on screen rotation? Need i to do it myself or it will be SFMLES's job?

But first of all it is necessary to LostFocus/GainedFocus events.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on April 20, 2014, 07:56:01 pm
Screen rotation should be nothing more than a resize event. If Jonathan did it like on iOS, it should work out of the box.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 20, 2014, 08:02:58 pm
Oh, i was not tested game with single threaded mode. It can't active RenderContext after resize, so if in single threaded will be ok then it is my fault.
upd: Nope, single threaded can't activate context too.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 20, 2014, 08:45:58 pm
Screen rotation should be nothing more than a resize event. If Jonathan did it like on iOS, it should work out of the box.
It worked before, but with the latest version my screen freezes sometimes (with the example app). Going to standby and back on the phone reacts again but the SFML screen stays black. Doesn't seem to happen all the time though. Didn't have time to try to track it down so far.

But yes, overall, rotation should be a resize event and it worked before.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 21, 2014, 01:12:11 pm
Must sf::RenderTexture work in SFMLES?
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 21, 2014, 01:31:20 pm
sf::RenderTexture works for me.

As for the resize event bug, I'm working on it :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 21, 2014, 01:37:17 pm
Ok, and by the way VirtualKeyboard works only for latin text.

If i'll catch bug with sf::RenderTexture - i'll inform.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 22, 2014, 09:23:32 am
After merging ios_and_android with master fonts are broken again.
And AKEYCODE_DEL must be returned as backspace.
Title: Re: Android and iOS ports available for testing
Post by: nero81af on April 22, 2014, 05:05:58 pm
I'd like to submit here some patches I had to put in sfml in order to build ogre with sfml on android ios macos linux and windows with gl3plus renderer and gles2 renderer and mingw64 compiler. Some patches allow the creation of a es2.0 / 3.0 context.. not sure those are useful tho since sfml is working with gles 1.0 only.. anyway here they are (those patches should not broke actual build)

SFML/Window/EglContext.cpp: line 197.

    //const EGLint contextVersion[] = {
    //    EGL_CONTEXT_CLIENT_VERSION, 1,
    //    EGL_NONE
    //};
    //
    //EGLContext toShared;
    //
    //if (shared)
    //    toShared = shared->m_context;
    //else
    //    toShared = EGL_NO_CONTEXT;
    EGLint renderable;
    EGLint client_version;

    eglGetConfigAttrib(m_display,m_config,EGL_RENDERABLE_TYPE,&renderable);

    if(renderable == EGL_OPENGL_ES_BIT)
    {
        client_version = 1;
    }
    else if(renderable == EGL_OPENGL_ES2_BIT)
    {
        client_version = 2;
    }

    const EGLint contextVersion[] = {
        EGL_CONTEXT_CLIENT_VERSION, client_version,
        EGL_NONE
    };

    EGLContext toShared;

    if (shared && (client_version != 2))
        toShared = shared->m_context;
    else
        toShared = EGL_NO_CONTEXT;

SFML/Window/EglContext.cpp: line 260.

    // Set our video settings constraint
    //const EGLint attributes[] = {
    //    EGL_BUFFER_SIZE, bitsPerPixel,
    //    EGL_DEPTH_SIZE, settings.depthBits,
    //    EGL_STENCIL_SIZE, settings.stencilBits,
    //    EGL_SAMPLE_BUFFERS, settings.antialiasingLevel,
    //    EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
    //    EGL_RENDERABLE_TYPE, EGL_OPENGL_ES_BIT,
    //    EGL_NONE
    //};
    EGLint renderable;

    if(settings.majorVersion == 1)
    {
        renderable = EGL_OPENGL_ES_BIT;
    }
    else if(settings.majorVersion == 2)
    {
        renderable = EGL_OPENGL_ES2_BIT;
    }

    const EGLint attributes[] = {
        EGL_BUFFER_SIZE, bitsPerPixel,
        EGL_DEPTH_SIZE, settings.depthBits,
        EGL_STENCIL_SIZE, settings.stencilBits,
        EGL_SAMPLE_BUFFERS, ((settings.antialiasingLevel > 0) ? 1 : 0),
        EGL_SAMPLES, settings.antialiasingLevel,
        EGL_SURFACE_TYPE, EGL_WINDOW_BIT | EGL_PBUFFER_BIT,
        EGL_RENDERABLE_TYPE, renderable,
        EGL_NONE
    };

SFML/Window/Android/WindowImplAndroid.cpp: line 520.

    //case AKEYCODE_DEL                : return Keyboard::Delete;
    case AKEYCODE_DEL                : return Keyboard::BackSpace;
 
SFML/Window/Android/WindowImplAndroid.cpp: line 614.

    if(action == AKEY_EVENT_ACTION_UP)
    {
       unicode = 0;
    }

SFML/Window/iOS/SFAppDelegate.mm: line 269.

    if(character == '\b')
    {
        sf::Event event;
        event.type = sf::Event::KeyPressed;
        event.key.code = sf::Keyboard::BackSpace;
        event.key.alt = false;
        event.key.control = false;
        event.key.shift = false;
        sfWindow->pushEvent(event);
    }
    else if(character == '\n')
    {
        sf::Event event;
        event.type = sf::Event::KeyPressed;
        event.key.code = sf::Keyboard::Return;
        event.key.alt = false;
        event.key.control = false;
        event.key.shift = false;
        sfWindow->pushEvent(event);
    }

SFML/Window/iOS/SFView.mm: line 104.

    //sf::Vector2i position(static_cast<int>(point.x), static_cast<int>(point.y));
    sf::Vector2i position(static_cast<int>(point.x * self.contentScaleFactor), static_cast<int>(point.y * self.contentScaleFactor));

SFML/Window/iOS/SFView.mm: line 124.

    //sf::Vector2i position(static_cast<int>(point.x), static_cast<int>(point.y));
    sf::Vector2i position(static_cast<int>(point.x * self.contentScaleFactor), static_cast<int>(point.y * self.contentScaleFactor));

SFML/Window/iOS/SFView.mm: line 145.

    //sf::Vector2i position(static_cast<int>(point.x), static_cast<int>(point.y));
    sf::Vector2i position(static_cast<int>(point.x * self.contentScaleFactor), static_cast<int>(point.y * self.contentScaleFactor));

SFML/Window/Win32/JoystickImpl.cpp: line 235.

    //ss.str(_T(""));
    ss.str(sf::String(""));

SFML/Window/Win32/JoystickImpl.cpp: line 250.

    //ss.str(_T(""));
    ss.str(sf::String(""));
Title: Re: Android and iOS ports available for testing
Post by: Hiura on April 23, 2014, 12:02:10 am
Regarding the OS X part of your patch, the current master revision should already address those issue. Can you confirm that?
Title: Re: Android and iOS ports available for testing
Post by: nero81af on April 23, 2014, 10:25:38 am
those patches have been applied on the master branch from yesterday so no! opengl 3.0 context does not work without those patches
Title: Re: Android and iOS ports available for testing
Post by: Hiura on April 23, 2014, 10:46:18 am
Then there's some duplicate code. https://github.com/SFML/SFML/blob/master/src/SFML/Window/OSX/SFContext.mm#L189-L202 and https://github.com/SFML/SFML/blob/master/src/SFML/Window/OSX/SFContext.mm#L215-L232

You can create a pull request on github if you want. It will be easier to integrate your work then.
Title: Re: Android and iOS ports available for testing
Post by: nero81af on April 23, 2014, 12:38:34 pm
I edited my previous post! master branch has fixed problems regarding opengl 3.0 context creation.

while testing I found out another bug

JoystickImpl.mm and JoystickImpl.hpp in Ios folder are missing getIdentification method!
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 23, 2014, 12:59:06 pm
Sonkun, did you solved rotation bug?
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 23, 2014, 09:23:13 pm
Sorry, actually I'm on vacation and I didn't have enough time to find out the bug or answer the forum. I'll have time to work on SFML Friday evening and whole Saturday. I hope it can wait.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 24, 2014, 04:44:18 pm
Yes it can wait surely. =)
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 26, 2014, 12:08:53 pm
@nero81af: your patch sounds interesting. However it turns out I don't have enough time (because of the SFML team reorganization and the amount of discussion to read/reply) analyse and merge it. As for the rotation bug if you want to solve the bug, go ahead I would be glad to merge your changes. Otherwise, I'll be back on 28th of April thus I hope I can do it day after.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 26, 2014, 07:22:18 pm
I've made a little hack:
AAsset* GetAsset(const std::string& filename)
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        return AAssetManager_open(states->activity->assetManager, filename.c_str(), AASSET_MODE_UNKNOWN);
}
 
But i'm getting segfault on open. I cheked that states->activity is not null and assetManager is not null too. What it can be? My own bug, again.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 27, 2014, 08:00:54 pm
Here is log for rotation crash. I think it's OpenAL again.
04-27 21:37:07.432: E/AudioService(485): handleConfigurationChanged() createInstance IAudioServiceExt fail
04-27 21:37:07.432: E/AudioService(485): java.lang.RuntimeException
04-27 21:37:07.432: E/AudioService(485):        at com.mediatek.common.MediatekClassFactory.createInstance(MediatekClassFactory.java:550)
04-27 21:37:07.432: E/AudioService(485):        at android.media.AudioService.handleConfigurationChanged(AudioService.java:5916)
04-27 21:37:07.432: E/AudioService(485):        at android.media.AudioService.access$8500(AudioService.java:108)
04-27 21:37:07.432: E/AudioService(485):        at android.media.AudioService$AudioServiceBroadcastReceiver.onReceive(AudioService.java:4085)
04-27 21:37:07.432: E/AudioService(485):        at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:789)
04-27 21:37:07.432: E/AudioService(485):        at android.os.Handler.handleCallback(Handler.java:800)
04-27 21:37:07.432: E/AudioService(485):        at android.os.Handler.dispatchMessage(Handler.java:100)
04-27 21:37:07.432: E/AudioService(485):        at android.os.Looper.loop(Looper.java:194)
04-27 21:37:07.432: E/AudioService(485):        at com.android.server.ServerThread.run(SystemServer.java:1304)
04-27 21:37:07.494: E/WeatherApp(17889): ACTION_CONFIGURATION_CHANGED
04-27 21:37:07.536: E/WidgetUtils(17889): cityCode=cityId:292195

04-27 21:37:08.149: A/libc(19415): Fatal signal 11 (SIGSEGV) at 0x006f0072 (code=1), thread 19459 (om.example.sfml)
04-27 21:37:08.393: E/InputDispatcher(485): channel '41f9b640 com.example.sfml/android.app.NativeActivity (server)' ~ Channel is unrecoverably broken and will be disposed!

04-27 21:37:08.984: E/AudioService(485): handleConfigurationChanged() createInstance IAudioServiceExt fail
04-27 21:37:08.984: E/AudioService(485): java.lang.RuntimeException
04-27 21:37:08.984: E/AudioService(485):        at com.mediatek.common.MediatekClassFactory.createInstance(MediatekClassFactory.java:550)
04-27 21:37:08.984: E/AudioService(485):        at android.media.AudioService.handleConfigurationChanged(AudioService.java:5916)
04-27 21:37:08.984: E/AudioService(485):        at android.media.AudioService.access$8500(AudioService.java:108)
04-27 21:37:08.984: E/AudioService(485):        at android.media.AudioService$AudioServiceBroadcastReceiver.onReceive(AudioService.java:4085)
04-27 21:37:08.984: E/AudioService(485):        at android.app.LoadedApk$ReceiverDispatcher$Args.run(LoadedApk.java:789)
04-27 21:37:08.984: E/AudioService(485):        at android.os.Handler.handleCallback(Handler.java:800)
04-27 21:37:08.984: E/AudioService(485):        at android.os.Handler.dispatchMessage(Handler.java:100)
04-27 21:37:08.984: E/AudioService(485):        at android.os.Looper.loop(Looper.java:194)
04-27 21:37:08.984: E/AudioService(485):        at com.android.server.ServerThread.run(SystemServer.java:1304)
04-27 21:37:09.103: E/WidgetUtils(17889): cityCode=cityId:292195
04-27 21:37:09.118: E/WeatherApp(17889): ACTION_CONFIGURATION_CHANGED
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 28, 2014, 11:59:36 am
Adding "orientation" to manifest fixed crash. But view not changed in example project. My croger controls view itself, so it works on 4.2.x Android.
      android:configChanges="keyboardHidden|screenSize|orientation"
 
As i understand it won't work with Android 2.3.3.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 28, 2014, 04:26:16 pm
Well, who is intrested, can download full android alpha - https://www.dropbox.com/s/409org6py72zkq7/croger.apk
I think it won't run on API < 13 and it crahes on stop/continue, i.e. you can't answer to call or read SMS and then return to game now. Fixed.
Now i see only one serious bug - NativeActivity not killed on exit. And when i'll run game again, there are just black screen, i need to kill app manually then start. Example has this bug too. Looks like onDestroy is not called on window close.
As i understand ANativeActivity_finish() does only  mark to wish finish, and app has to be alive while onDestroy is awaiting to be called.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 29, 2014, 07:19:36 pm
Interesting! Actually, I noticed the activity not properly destroyed bug when working on the rotation bug (and that's why I needed more time :p). But I don't understand why we still see the application as running because the code is called as intended. onDestroy() takes care of sending the SFML close event, the main loop ends which ends the main() function, which  causes ANativeActivity_finish() to be called.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on April 29, 2014, 07:32:01 pm
I inserted log messages in the onDestroy function, i haven't seen any message. In the same time messages in the terminateMain was displayed.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on April 29, 2014, 07:49:54 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: cloudncali on April 30, 2014, 06:52:03 am
I am currently getting compile errors on the Rpi with the latest SFML build

http://pastebin.com/Be4jJjUs

Title: Re: Android and iOS ports available for testing
Post by: Sonkun on May 03, 2014, 06:26:08 pm
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 ?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 03, 2014, 06:37:15 pm
Quote
Thanks, I fixed it locally with another bug
Make sure you're in sync with this commit (https://github.com/SFML/SFML/commit/132f4764c3f190fe46408da6f25bbdc46fa97410) in another branch.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on May 06, 2014, 02:44:43 pm
Make sure you're in sync with this commit (https://github.com/SFML/SFML/commit/132f4764c3f190fe46408da6f25bbdc46fa97410) 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.
Title: Re: Android and iOS ports available for testing
Post by: dk123 on May 06, 2014, 03:34:48 pm
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

Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 06, 2014, 04:05:04 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Cranberry on May 07, 2014, 09:17:43 pm
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?
Title: Re: Android and iOS ports available for testing
Post by: dk123 on May 08, 2014, 03:30:15 am
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.


Title: AW: Re: Android and iOS ports available for testing
Post by: eXpl0it3r on May 08, 2014, 07:47:38 am
It may perhaps be worthwhile to send Erik another email to ask if there's been process over the last 8 months.
Already happened.
Title: Re: Android and iOS ports available for testing
Post by: Gammenon on May 08, 2014, 07:24:49 pm
My vote for that change to support WAV, OGG and iOS's formats getting rid of libsnd
Title: Re: Android and iOS ports available for testing
Post by: nottrulyevil on May 11, 2014, 10:10:20 pm
Should a new sub-forum be opened for these ports?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 11, 2014, 11:12:46 pm
Quote
Should a new sub-forum be opened for these ports?
Why? Is there a Linux, Windows or Mac OS X sub-forum? ???
Title: Re: Android and iOS ports available for testing
Post by: math07 on May 15, 2014, 09:40:19 pm
I've found a bug on Android with texture repeating (using the example) :

(http://img15.hostingpics.net/pics/281991sfmlbugrepeat.png)
The sprite should be exactly 4 SFML logos

Here is the code :
(click to show/hide)
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 15, 2014, 10:51:05 pm
This is not a bug, only a limitation of your GPU, as stated in the doc:

Quote
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.
Title: Re: Android and iOS ports available for testing
Post by: leafdj on May 16, 2014, 10:00:42 am
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:

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.
Title: Re: Android and iOS ports available for testing
Post by: math07 on May 16, 2014, 04:51:41 pm
This is not a bug, only a limitation of your GPU, as stated in the doc:

Ok, thanks for the answer.
Title: Re: Android and iOS ports available for testing
Post by: cloudncali on May 18, 2014, 09:11:19 pm
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
Title: Re: Android and iOS ports available for testing
Post by: myl on May 21, 2014, 03:02:53 pm
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
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 21, 2014, 03:52:16 pm
I thought it was already fixed... I'll take care of that ASAP.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 21, 2014, 08:28:01 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: myl on May 21, 2014, 08:42:29 pm
I thought it was already fixed... I'll take care of that ASAP.

Thanks! :)
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 21, 2014, 08:45:59 pm
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?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 21, 2014, 08:47:16 pm
Quote
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 ;)

Quote
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.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 21, 2014, 09:03:31 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 21, 2014, 10:58:23 pm
Quote
Happy now?
No ;D

You PR no longer matches its title and description. You should at least add a message that explains what you changed.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 21, 2014, 11:13:41 pm
Nitpicka! Fixed. :)
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 28, 2014, 07:52:29 pm
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 (http://developer.android.com/guide/topics/sensors/sensors_overview.html#table2), 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.

Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 28, 2014, 07:59:11 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 28, 2014, 08:02:39 pm
Okay, the source comment gave me the impression they've been left out just due to (possibly outdated) docs.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 28, 2014, 09:19:16 pm
Which comment?
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 28, 2014, 09:32:56 pm
Code: [Select]
    // These sensors are unavailable from the Android C API
    if ((sensor == Sensor::Gravity) ||
        (sensor == Sensor::UserAcceleration) ||
        (sensor == Sensor::Orientation))
        return NULL;
Title: Re: Android and iOS ports available for testing
Post by: Laurent on May 28, 2014, 11:01:24 pm
Hmm... yes, looks strange.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on May 30, 2014, 07:07:00 pm
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
Title: Re: Android and iOS ports available for testing
Post by: Hiura on May 30, 2014, 07:08:02 pm
That might be related to https://github.com/SFML/SFML/issues/621.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on June 01, 2014, 10:47:09 pm
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
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 01, 2014, 10:59:12 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on June 01, 2014, 11:19:27 pm
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
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 01, 2014, 11:31:58 pm
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 (https://www.durovis.com/index.html). 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.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on June 02, 2014, 12:19:21 am
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  8)


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



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on June 07, 2014, 05:34:52 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on June 07, 2014, 05:40:04 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 07, 2014, 06:01:46 pm
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.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on June 08, 2014, 08:18:27 am
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 ?
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 08, 2014, 08:51:55 am
Hm... with latest master I no longer get any audio output and then another segfault after a few seconds.
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 08, 2014, 12:57:15 pm
Hah! Got it working again (and this time my source and build directories for OpenAL are in a clean and tidy state; I've somehow had quite a mess before). :)

I only had to perform one tiny adjustment:

Code: [Select]
#SET_TARGET_PROPERTIES(${LIBNAME} PROPERTIES VERSION ${LIB_VERSION})
Title: Re: Android and iOS ports available for testing
Post by: arbitergoten on June 15, 2014, 10:34:03 pm
when I call ndk-build on the sfml android example i get this error

Android NDK: WARNING: APP_PLATFORM android-17 is larger than android:minSdkVersion 9 in ./AndroidManifest.xml   
Android NDK: jni/Android.mk: Cannot find module with tag 'sfml' in import path   
Android NDK: Are you sure your NDK_MODULE_PATH variable is properly defined ?   
Android NDK: The following directories were searched:   
Android NDK:         
jni/Android.mk:18: *** Android NDK: Aborting.    .  Stop.
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 15, 2014, 10:39:07 pm
Sounds like "make install" for SFML somehow failed. Do you have the directory [ndk]/sources/sfml?
Title: Re: Android and iOS ports available for testing
Post by: arbitergoten on June 16, 2014, 11:24:05 am
no I don't  have [ndk]/sources/sfml

this is how my cmake-gui looks like

source code: /home/heresh/Downloads/SFML-master/

where to build: /home/heresh/Documents/sfml-build


BUILD_SHARED_LIBS =  TRUE
CMAKE_BUILD_TYPE  = Release
CMAKE_INSTALL_PREFIX = /usr/local
GLEW_INSTALL_PATH = /usr/include
GLEW_LIBRARY  = /usr/lib/i386-linux-gnu/libGLEW.so
SFML_BUILD_DOC      =    TRUE
SFML_BUILD_EXAMPLES       =   TRUE
SFML_INSTALL_PKGCONFIG_FILES    =   TRUE
SFML_OPENGL_ES    =    TRUE
UDEV_INCLUDE_DIR  =  /usr/include
UDEV_LIBRARIES  = /usr/lib/i386-linux-gnu/libudev.so

then i go to  where it put the build files and call
make
sudo make install

and everything works fine no errors


 
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 16, 2014, 01:47:23 pm
Ah, you're building and installing the desktop version of SFML I guess. Building for Android is a bit more complicated unfortunately. :) I'll see if I have time to write some short readme/guide for the wiki.
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 16, 2014, 03:57:53 pm
Okay, started a new wiki page explaining building SFML for Android (https://github.com/SFML/SFML/wiki/Building-SFML-for-Android). It's still incomplete and might contain mistakes as well. If anyone feels like improving the page, go for it!
Title: Re: Android and iOS ports available for testing
Post by: Nexus on June 16, 2014, 04:01:05 pm
Very nice Mario, thanks a lot! That will certainly open the Android port for more people, and it could even be used as inspiration for the official tutorials :)
Title: Re: Android and iOS ports available for testing
Post by: Lo-X on June 16, 2014, 04:22:52 pm
Okay now you're talkin' :) Thanks Mario, I needed that stuff :)
Title: Re: Android and iOS ports available for testing
Post by: Peixinho on June 26, 2014, 03:29:50 pm
Hi there,

is there any way to build a GL ES2.0 context? Can't seem to find any solution.

Thanks
Title: Re: Android and iOS ports available for testing
Post by: Laurent on June 26, 2014, 03:49:32 pm
Nop, at the moment SFML is entirely based on GL ES 1.1.
Title: Re: Android and iOS ports available for testing
Post by: Peixinho on June 26, 2014, 04:09:42 pm
I just need the context, the rest of it is handle by me. Just want to use the window and events with SFML.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on June 26, 2014, 05:51:20 pm
It is currently hard-coded. On iOS (EAGL) it should be farily easy to turn it into a public option, I don't know about EGL (Linux / Android).
Title: Re: Android and iOS ports available for testing
Post by: Peixinho on June 26, 2014, 06:50:08 pm
That would be great if it could go public option!
Title: Re: Android and iOS ports available for testing
Post by: XeRaCKeR on July 08, 2014, 10:23:07 pm
Hi

I already built SFML-2.1 for android with mingw x32-4.8.1-posix-dwarf-rev3

(http://i.imgur.com/ADWgDNe.png)

It's all I need? I'm quite disorientated and I don't know how to compile my code for android

Title: Re: Android and iOS ports available for testing
Post by: Mario on July 08, 2014, 11:07:41 pm
https://github.com/SFML/SFML/wiki/Building-SFML-for-Android

To write some actual app, have a look at the Android example.
Title: Re: Android and iOS ports available for testing
Post by: XeRaCKeR on July 09, 2014, 12:29:20 am
https://github.com/SFML/SFML/wiki/Building-SFML-for-Android

To write some actual app, have a look at the Android example.

Yes, I followed this guide, but how to compile?
Title: Re: Android and iOS ports available for testing
Post by: Ixrec on July 09, 2014, 08:01:05 am
That guide uses CMake, so you tell it what compiler you want and it will generate the appropriate makefile/project file/whatever which you then use to do the actual compilation in whatever way is normal for your compiler.  It even gives the example that on Linux the actual compilation would be make && sudo make install.  For something like Visual Studio obviously you would open the project file and then tell VS to build the project.  Reading the official CMake tutorial might help: http://www.sfml-dev.org/tutorials/2.1/compile-with-cmake.php
Title: Re: Android and iOS ports available for testing
Post by: XeRaCKeR on July 09, 2014, 08:05:39 am
That guide uses CMake, so you tell it what compiler you want and it will generate the appropriate makefile/project file/whatever which you then use to do the actual compilation in whatever way is normal for your compiler.  It even gives the example that on Linux the actual compilation would be make && sudo make install.  For something like Visual Studio obviously you would open the project file and then tell VS to build the project.  Reading the official CMake tutorial might help: http://www.sfml-dev.org/tutorials/2.1/compile-with-cmake.php

I already compiled/built SFML with CMAKE, I mean how to compile my code for android apps to .apk? how to create a project, in code::blocks, for example.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on July 09, 2014, 09:46:12 am
how to create a project, in code::blocks, for example.
Well, i'm working on it now. I have no results yet, but i have several thoughts. By the first i copied XML where ARM compiler declared. Then i'll adapt it for NDK toolchain - it's not problem for one single computer. After building source C::B will run afterbuild script which will create APK. So, it looks pretty simple and at least possible. But my main target is debugging code with C::B and i don't know how to do it yet, but think it possible too.
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on July 09, 2014, 06:34:32 pm
Quickly:
Compile SFML using CMake, it should look like this:
Quote
export ANDROID_NDK=/path/to/ndk
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_ABI=armeabi ..
make
make install

The last command, make install, will install everything in your NDK (headers, libraries, bootstrap).

From now, just create a regular native Android project (actually, just copy and adjust the example provided in SFML source, it'll be easier), compile and run. Refer to the example to write your app Android.mk and Application.mk scripts. It should look like this:

cd path/to/your/android-project
$ANDROID_NDK/ndk-build  # this line compiles your project)

Then press the run button from your IDE.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on July 12, 2014, 08:53:13 am
cd path/to/your/android-project
$ANDROID_NDK/ndk-build  # this line compiles your project)

Then press the run button from your IDE.


Why not just adding native support to your project (Right-click on project -> Android tools -> Add Native Support) and let eclipse compile your project?

Another advantage, you will have code completion and eclipse will report c++ errors too.


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: nero81af on July 22, 2014, 10:00:58 am
Just a quick question: is there a way to obtain the native activity outside sfml? I need access to obbpath and assetmanager to extract game data! :D Maybe it would be nice to obtain it from getSystemHandle instead of the native window!
Title: Re: Android and iOS ports available for testing
Post by: Mario on July 22, 2014, 10:43:24 am
Not yet.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 08, 2014, 08:39:59 pm
Anyone tried new NDK10? I wonder why $NDK/platforms is empty except "android-L". cmake can't configure make files without "android-9", i copied it, just for test, from previous NDK and cmake configured make files successfully. But, as expected, there were problems with linkage.
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 08, 2014, 09:15:20 pm
Just updating and my Platforms folder has all the previous versions. Are you sure you downloaded the correct package? (Windows x64 here)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 08, 2014, 09:22:51 pm
I'm using Ubuntu for building for android.  :o Well, i think i can copy these files from Windows package.
upd: Yes, i'd downloaded wrong package. There are new target now - arm64.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 10, 2014, 05:09:01 pm
I can share some hacks for my games. Currently it placed in System/Err.hpp and System/Err.cpp

#if defined(SFML_SYSTEM_ANDROID)

#include <string>

class AAsset;
class ANativeActivity;

namespace sf
{


SFML_SYSTEM_API AAsset* GetAsset(const std::string& filename); // for reading files from the Assets
SFML_SYSTEM_API ANativeActivity* GetActivity(); // not used yet
SFML_SYSTEM_API std::string GetLanguage(); // return something like "En_en"
SFML_SYSTEM_API std::string GetInternalDataPath();  // you know what is it =)
SFML_SYSTEM_API std::string GetExternalDataPath(); // and it


} // namespace sf

#endif

#if defined(SFML_SYSTEM_ANDROID)

namespace sf
{

AAsset* GetAsset(const std::string& filename)
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        return AAssetManager_open(states->activity->assetManager, filename.c_str(), AASSET_MODE_UNKNOWN);
}



ANativeActivity* GetActivity()
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        return states->activity;
}



std::string GetLanguage()
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        char lng[3] = { 0 };
        AConfiguration_getLanguage(states->config, lng);
        return std::string(lng);
}



std::string GetInternalDataPath()
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        const char* path = states->activity->internalDataPath;
        return path ? std::string(path) : "";
}



std::string GetExternalDataPath()
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        const char* path = states->activity->externalDataPath;
        return path ? std::string(path) : "";
}

} // namespace sf
#endif

These things are necessary! I don't know how to say it in english... That functional MUST BE provided by SFML.

By the way, i'm using C::B to build  game, and now i'm trying to debug via C::B.
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 10, 2014, 06:37:10 pm
I've noticed the same limitation last week, but the whole asset loading is already there, just not exposed. I thought about adding something like sf::String::loadFromFile(). It should still be able to read binary files as well. And most important: The code should work cross-platform. :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 10, 2014, 06:44:19 pm
I'm using my own ResourceManager, where 99% of files are loaded via sf::InputStream interface. It pretty good to universal reading of data from files or archives and my Lua's "require" is modified to use it, so i need full access to Assets. And I'm not using ::loadFromFile at all.  Now i'm using assets just once, when app runs first time it copies game's data files from Assets to app's data dir. To be honest, there are only one "data files" - resource.pak.
By the way, is "orientation" works now? I updated master branch to last state and Android's screen now is vertical only.
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 10, 2014, 08:09:47 pm
It should work just fine (triggers resize events). Just check the example app.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 26, 2014, 08:47:37 pm
static void onPause(ANativeActivity* activity)
{
    // Retrieve our activity states from the activity instance
    sf::priv::ActivityStates* states = sf::priv::retrieveStates(activity);
    sf::Lock lock(states->mutex);

    // Send an event to warn people the activity has been paused
    sf::Event event;
    event.type = sf::Event::MouseLeft;

    states->forwardEvent(event);
}
Why there used "MouseLeft" event? I think "LostFocus" is better.

But it is not important. I'm entering to this function when i'm exiting from my "main". If i'm calling "window->close()" before - the same. I want to get in "onDestroy" function!
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on August 26, 2014, 08:57:18 pm
I already created an issue about this topic: https://github.com/SFML/SFML/issues/653

The problem is there should be a way to differ if onPause or onStop is called, because maybe you want to do different things.

AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 26, 2014, 09:01:33 pm
AlexAUT, do you have any trouble with exiting from app? I can normally launch/exit only once, then i need to kill app manually to launch app again. As i see in the debugger - "onDestroy" function is never called.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on August 26, 2014, 09:21:15 pm
onDestroy is only called when app gets deleted from the memory, for example when the system is low on memory... So its ok when onDestroy isn't called.


What do you mean with "exiting from app", do you mean when the user presses the home button? Or do you mean when your code closes the app -> main returns?
For the first case I have no problem, sf::Event::LostEvent/MouseLeft are called and sf::Event::GainFocuse/MouseEntered are called.
For the latter case I use exit(0) to close the app, otherwise I have problems when I open the app again.



AlexAUT



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 26, 2014, 09:24:05 pm
For the latter case I use exit(0) to close the app, otherwise I have problems when I open the app again.
That what i need, thank you!
Title: Re: Android and iOS ports available for testing
Post by: Jesper Juhl on August 26, 2014, 09:26:11 pm
For the latter case I use exit(0) to close the app, otherwise I have problems when I open the app again.
That what i need, thank you!
Just remember that "exit(0)" won't run any destructors...
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 26, 2014, 09:29:50 pm
No problems here either. Works fine as well.

Here's a compiled/packaged version of the SFML example app featuring a simple modification that will print out all events happening, making it easier to see which events are fired: https://dl.dropboxusercontent.com/u/2510538/SFML-Example-debug.apk
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on August 26, 2014, 09:32:11 pm
Just remember that "exit(0)" won't run any destructors...
Yes, I know. =) But I would never have thought of using "exit" to quit app. I just forget about it. Now I can place my games at stores.  8)
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on August 26, 2014, 09:43:25 pm
Just remember that "exit(0)" won't run any destructors...

The problem is what are the options? When I return normally the user can't open the game again, so I created the "engine" on the heap and delete it myself before I exit(0) (btw I have no globals), but I don't know about the SFML global stuff   :-\



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 26, 2014, 09:49:47 pm
This sounds like you've got some bug somewhere, possibly a race condition with static constructors/destructors?
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on August 26, 2014, 09:51:57 pm
It also happens with the SFML-example, so I guess its not a problem with my codebase, also it does not happen on every device. Sadly I can't test it because I haven't my phone for ~2weeks (broke it last week  :'( )


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 26, 2014, 09:57:38 pm
There used to be a bug similar to that in event handling a few weeks ago. Make sure you actually rebuild from scratch (delete the bin/libs/obj sub dirs), then build again. Just issuing "ndk-build" or "ndk-build -B" doesn't seem to always do the trick.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on August 26, 2014, 10:19:01 pm
Okay, I will try it when i have my phone back.


AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: leafdj on September 07, 2014, 09:04:54 pm
Quick question about resource management on Android, I'm having a bit of a tough time reading a .txt file that I have defined in assets. I'm using an ifstream which works fine on Windows, but won't work on Android because the file is contained in the .apk. Is there a way to use the SFML Resource Manager that's used by Image Loading, etc., or is it better just to directly use the android asset manager?
Is there a way that I can get a reference to the file that can be treated the same way as the ifstream?
ie stream >> line?
Title: Re: Android and iOS ports available for testing
Post by: Mario on September 07, 2014, 10:27:17 pm
It's not exposed yet, you'd have to write your own code around that. But I'm having the same issue, so very likely to submit something soon™.
Title: Re: Android and iOS ports available for testing
Post by: leafdj on September 07, 2014, 10:34:44 pm
It's not exposed yet, you'd have to write your own code around that. But I'm having the same issue, so very likely to submit something soon™.

Okay, thanks for the reply Mario. Wasn't sure if I was just missing a piece of the puzzle or not. I'll try and tinker with it a bit and see if I can make something work.
Title: Re: Android and iOS ports available for testing
Post by: Mario on September 08, 2014, 03:40:31 pm
As a temporary solution, all you'd need would be "src/SFML/System/Android/ResourceStream.hpp" to access `sf::priv::ResourceStream`. No need for further custom code.
Title: Re: Android and iOS ports available for testing
Post by: leafdj on September 09, 2014, 04:54:01 am
Ah, perfect. I was trying to replicate the functionality in ResourceStream on my own. I didn't know I could simply move the header file to get access to it. Everything looks like its working, thanks for the help!
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 10, 2014, 07:35:02 pm
Little hack for assets' streaming and it works:

I inserted this in Err.hpp:
#if defined(SFML_SYSTEM_ANDROID)

#include <string>

class AAsset;

namespace sf
{

SFML_SYSTEM_API AAsset* GetAsset(const std::string& filename, int assetMode = 0 /* AASSET_MODE_UNKNOWN */);

} // namespace sf

#endif

Err.cpp
#if defined(SFML_SYSTEM_ANDROID)  
        #include <SFML/System/Android/Activity.hpp>
        #include <SFML/System/Lock.hpp>
        #include <android/configuration.h>
#endif

....
// in sf namespace

#if defined(SFML_SYSTEM_ANDROID)

AAsset* GetAsset(const std::string& filename, int assetMode /* AASSET_MODE_UNKNOWN */)
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        return AAssetManager_open(states->activity->assetManager, filename.c_str(), assetMode);
}

#endif
 

Asset stream derived from sf::InputStream:
#ifndef __GIPE_ASSET_STREAM_H__
#define __GIPE_ASSET_STREAM_H__

class AAsset;

class AssetStream: public GipeStream::IInputStream // it's a little extended sf::InputStream
{
public:

        explicit AssetStream() = default;
        explicit AssetStream(const FileNameType& name);
        virtual ~AssetStream();

        void close();
        bool open(const FileNameType& filename);

        virtual sf::Int64 read(void* data, sf::Int64 size) override;
        virtual sf::Int64 seek(sf::Int64 position) override;
        virtual sf::Int64 tell() override;
        virtual sf::Int64 getSize() override;

        AssetStream(AssetStream& other) = delete;
        void operator=(const AssetStream&) = delete;

        AssetStream(AssetStream&& other);

private:

        AAsset*         mAsset = nullptr;
};



#endif // __GIPE_ASSET_STREAM_H__
 

#include "pch.h"
#include "filesystem/assetstream.h"
#include <android/asset_manager.h>


AssetStream::AssetStream(const FileNameType& name):
        GipeStream::IInputStream(name)
{
        mIsOk = open(name);
}



AssetStream::AssetStream(AssetStream&& other):
        IInputStream(std::move(other)),
        mAsset(std::move(other.mAsset))
{
        other.mAsset = nullptr;
}



AssetStream::~AssetStream()
{
        close();
}



void AssetStream::close()
{
        if (mAsset)
        {
                AAsset_close(mAsset);
                mAsset = nullptr;
        }
}



bool AssetStream::open(const FileNameType& filename)
{
        close();
        mIsOk = false;
        AAsset* file = sf::GetAsset(filename.c_str(), AASSET_MODE_STREAMING);

        if (file)
        {
                mAsset = file;
                mIsOk = true;
        }

        return mIsOk;
}



/* override */ sf::Int64 AssetStream::read(void* data, sf::Int64 size)
{
        return mIsOk ? (sf::Int64) AAsset_read(mAsset, data, size) : -1;
}



/* override */ sf::Int64 AssetStream::seek(sf::Int64 position)
{
        return mIsOk ? AAsset_seek(mAsset, position, SEEK_SET) : -1;
}



/* override */ sf::Int64 AssetStream::tell()
{
        return mIsOk ? AAsset_seek(mAsset, 0, SEEK_CUR) : -1;
}



/* override */ sf::Int64 AssetStream::getSize()
{
        return mIsOk ? AAsset_getLength(mAsset) : -1;
}
 
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on September 10, 2014, 09:59:17 pm
Someone else having problems which certain fonts at certaint sizes? Because sometimes sf::Text is destroying the rendering, it looks like the backbuffer doesn't get updated anymore so display will always "show" the last frame and the current frame (in a loop, gamelogic still runs fine). Kinda hard to describe. I had a similiar problem with my opengl engine where I forgot to "unbind" a FBO, looked exactly the same.

Grimmreefer has also experienced this issue so I think it is related to SFML, sadly I can't reproduce it right know (but its still there I changed the font/font-size in Kroniax about 5times to avoid this issue)



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 11, 2014, 10:43:02 am
I'm not sure about your bug, but may be... All my problems with fonts were with "loadFromFile" or stream's bug. Now i'm using "loadFromStream" only and have no problems with any language.
Title: Re: Android and iOS ports available for testing
Post by: FancyPants on September 12, 2014, 04:19:03 pm
I've been tinkering with SFML for a short while and I'd like to request some assistance and troubleshoot some issues I'm experiencing... :)

I use the bleeding edge master available at https://github.com/SFML/SFML. Here's a short piece of test code.

#include <iostream>
#include <SFML/Main.hpp>
#include <SFML/Graphics.hpp>

int main(int argc, char **argv) {
        sf::VideoMode videoMode = sf::VideoMode::getFullscreenModes()[0];
        std::cout << videoMode.width << "x" << videoMode.height << "@" << videoMode.bitsPerPixel << std::endl;
        sf::RenderWindow window(videoMode, "Test", sf::Style::Fullscreen);
        sf::RectangleShape rect(sf::Vector2f(window.getSize().x / 2, window.getSize().y / 8));
        rect.setFillColor(sf::Color::Red);
        sf::Event event;

        while (window.isOpen()) {
                while (window.pollEvent(event)) {
                        if ((event.type == sf::Event::Closed) || ((event.type == sf::Event::KeyPressed) && (event.key.code == sf::Keyboard::Escape))) {
                                window.close();
                        }
                }
                window.clear(sf::Color(sf::Color::Blue));
                window.draw(rect);
                window.display();
        }

        exit(0);
}
 

Android (test hardware, Nexus 5 and OnePlus One):
1. I experience the same issue AlexAUT and ChronicRat with the application crashing when backing out of it. I currently work around the issue by also using exit(0).
2. Crash upon pressing the "Home" button. AlexAUT and ChronicRat, how did you work around it?

iOS (test hardware: iPod touch, 4th Gen from 2011 running iOS6)
1. Does not compile unless I comment out line 94 from SFML/Window/JoystickManager.cpp -- item.identification = item.joystick.getIdentification();
2. Using the test code above, I get the resolution 480x320@32, but it appears to work in portrait mode. Upon rotating to landscape, the drawing looks even more funny. It does not matter if I change the application orientation int he project. Please see the enclosed screenshots.
3. The image loading works with JPEG, but fails when trying to open PNG (Failed to load image "res_texture.png". Reason : Corrupt PNG).
4. Crashes when killing the application from the "task bar". Here's a stack trace.
* thread #1: tid = 0x2503, 0x3b899eb4 libsystem_kernel.dylib`mach_msg_trap + 20, queue = 'com.apple.main-thread', stop reason = signal SIGKILL
    frame #0: 0x3b899eb4 libsystem_kernel.dylib`mach_msg_trap + 20
    frame #1: 0x3b89a04c libsystem_kernel.dylib`mach_msg + 40
    frame #2: 0x372256c6 GraphicsServices`_GSSendEvent + 450
    frame #3: 0x37224510 GraphicsServices`GSSendEvent + 132
    frame #4: 0x3553af20 UIKit`_sendPendingApplicationSuspendEvent + 44
    frame #5: 0x355344a2 UIKit`_UIApplicationHandleEvent + 7058
    frame #6: 0x372265a2 GraphicsServices`_PurpleEventCallback + 590
    frame #7: 0x372261d2 GraphicsServices`PurpleEventCallback + 34
    frame #8: 0x33701172 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 34
    frame #9: 0x33701116 CoreFoundation`__CFRunLoopDoSource1 + 138
    frame #10: 0x336fff98 CoreFoundation`__CFRunLoopRun + 1384
    frame #11: 0x33672ebc CoreFoundation`CFRunLoopRunSpecific + 356
    frame #12: 0x33672d48 CoreFoundation`CFRunLoopRunInMode + 104
  * frame #13: 0x0002152a Proto`sf::priv::WindowImplUIKit::processEvents(this=0x1f1adc00) + 50 at WindowImplUIKit.mm:93
    frame #14: 0x0001970c Proto`sf::priv::WindowImpl::popEvent(this=0x1f1adc00, event=0x2fdf89ac, block=false) + 56 at WindowImpl.cpp:120
    frame #15: 0x00018ee0 Proto`sf::Window::pollEvent(this=0x2fdf8b24, event=0x2fdf89ac) + 52 at Window.cpp:187
    frame #16: 0x000134de Proto`sfmlMain(argc=0, argv=0x00000000) + 658 at main.cpp:17
    frame #17: 0x0001cc68 Proto`-[SFAppDelegate runUserMain](self=0x1ed16ec0, _cmd=0x0003846b) + 24 at SFAppDelegate.mm:67
    frame #18: 0x3403a276 Foundation`__NSFireDelayedPerform + 450
    frame #19: 0x337015de CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
    frame #20: 0x33701290 CoreFoundation`__CFRunLoopDoTimer + 272
    frame #21: 0x336fff00 CoreFoundation`__CFRunLoopRun + 1232
    frame #22: 0x33672ebc CoreFoundation`CFRunLoopRunSpecific + 356
    frame #23: 0x33672d48 CoreFoundation`CFRunLoopRunInMode + 104
    frame #24: 0x372252ea GraphicsServices`GSEventRunModal + 74
    frame #25: 0x35588300 UIKit`UIApplicationMain + 1120
    frame #26: 0x000355c8 Proto`main(argc=1, argv=0x2fdf9d28) + 36 at MainiOS.mm:60
Title: Re: Android and iOS ports available for testing
Post by: Mario on September 12, 2014, 04:31:00 pm
Doesn't crash for me on my Nexus 5 using the r10 NDK. However, it seems like the app is once again trying to use the context even while it's not active (so has no context). Definitely no crash happening, though.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on September 12, 2014, 06:18:55 pm
2. Crash upon pressing the "Home" button. AlexAUT and ChronicRat, how did you work around it?

Which android version do you use? 4.4? Because I remember a friend told me about the home button issue on his nexus with 4.4.



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 12, 2014, 06:37:02 pm
2. Crash upon pressing the "Home" button. AlexAUT and ChronicRat, how did you work around it?
I have no crash with Home, but i'm catching LostFocus and whole app is paused untill GainFocus raised. Tested on 4.2.2 and 2.3.6
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 14, 2014, 07:23:20 pm
Hmm, 2.3.x does not work now. And i'm not sure that it worked before. The same build perfectly works on several 4.x.x devices.

E/AndroidRuntime(18584): FATAL EXCEPTION: main
E/AndroidRuntime(18584): java.lang.RuntimeException: Unable to start activity ComponentInfo{com.familyxoft.croger/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to find native library: sfml-activity
E/AndroidRuntime(18584):        at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1647)
 
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on September 14, 2014, 07:32:02 pm
And i'm not sure that it worked before.

Nope, since I first tested eSFML (was a fork from Sonkun and then got pushed into the main repo):

In my experience it runs only on 4.1+ and on some 4.0.x device. Hower the native activity example runs on my Galaxy S1 (2.3.4) without problems so something in SFML destroys the compatibility to the old versions.



AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 14, 2014, 07:45:04 pm
Main problem is to load sfml-activity. May be little loader on Java will help.
Secondary problem, for me, there is bug with activity->internal(external)DataPath, it always NULL. This bug was fixed since 3.0.
Little hack for it, but i can't test it because main problem is not solved. =)
std::string GetInternalDataPath()
{
        priv::ActivityStates* states = priv::getActivity(NULL);
        Lock(states->mutex);
        const char* path = states->activity->internalDataPath;
       
        if (!path)
        {
                JNIEnv* jni;
                states->activity->vm->AttachCurrentThread(&jni, NULL);

                jclass activityClass = jni->GetObjectClass(states->activity->clazz);
                jmethodID getFilesDir = jni->GetMethodID(activityClass, "getFilesDir", "()Ljava/io/File;");
                jobject fileObject = jni->CallObjectMethod(states->activity->clazz, getFilesDir);
                jclass fileClass = jni->GetObjectClass(fileObject);
                jmethodID getAbsolutePath = jni->GetMethodID(fileClass, "getAbsolutePath", "()Ljava/lang/String;");
                jobject pathObject = jni->CallObjectMethod(fileObject, getAbsolutePath);
                path = jni->GetStringUTFChars((jstring)pathObject, NULL);

                jni->DeleteLocalRef(pathObject);
                jni->DeleteLocalRef(fileClass);
                jni->DeleteLocalRef(fileObject);
                jni->DeleteLocalRef(activityClass);

                states->activity->vm->DetachCurrentThread();
        }
       
        return path ? std::string(path) : "";
}
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 15, 2014, 07:48:05 pm
I just thinking, can be problem that we are using C++11? I'm using static STL, but what about libc.so?
This my crash log on 4.0.3 emulator:

F/libc    (  935): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
F/libc    (  935): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)
W/NetworkManagementSocketTagger(   79): setKernelCountSet(10013, 0) failed with errno -2
I/DEBUG   (   34): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   (   34): Build fingerprint: 'generic/sdk/generic:4.0.4/MR1/302030:eng/test-keys'
I/DEBUG   (   34): pid: 935, tid: 956  >>> com.familyxoft.croger_debug <<<
I/DEBUG   (   34): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr deadbaad
I/DEBUG   (   34):  r0 deadbaad  r1 001966f0  r2 80000000  r3 00000000
I/DEBUG   (   34):  r4 00000000  r5 00000027  r6 4003df28  r7 4004c474
I/DEBUG   (   34):  r8 505e1144  r9 001d8408  10 00000030  fp 51daf85c
I/DEBUG   (   34):  ip ffffffff  sp 51daf6e0  lr 4001f161  pc 4001b8c0  cpsr 60000030
I/DEBUG   (   34):  d0  4010000000000000  d1  3ff0000043a04000
I/DEBUG   (   34):  d2  000000003f000000  d3  000000003f000000
I/DEBUG   (   34):  d4  0000000000000000  d5  4026000000000000
I/DEBUG   (   34):  d6  447a000000000000  d7  41a0000041200000
I/DEBUG   (   34):  d8  0000000000000000  d9  0000000000000000
I/DEBUG   (   34):  d10 0000000000000000  d11 0000000000000000
I/DEBUG   (   34):  d12 0000000000000000  d13 0000000000000000
I/DEBUG   (   34):  d14 0000000000000000  d15 0000000000000000
I/DEBUG   (   34):  scr 80000012
I/DEBUG   (   34):
I/DEBUG   (   34):          #00  pc 000178c0  /system/lib/libc.so
I/DEBUG   (   34):          #01  pc 00013746  /system/lib/libc.so
I/DEBUG   (   34):          #02  pc 00015a84  /system/lib/libc.so (dlfree)
I/DEBUG   (   34):          #03  pc 000160fc  /system/lib/libc.so (free)
I/DEBUG   (   34):          #04  pc 002bbdd0  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN9__gnu_cxx13new_allocatorIcE10deallocateEPcj)
I/DEBUG   (   34):          #05  pc 002bb704  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSbIjSt11char_traitsIjESaIjEE4_Rep10_M_destroyERKS1_)
I/DEBUG   (   34):          #06  pc 002bae14  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSbIjSt11char_traitsIjESaIjEE4_Rep10_M_disposeERKS1_)
I/DEBUG   (   34):          #07  pc 002ba288  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSbIjSt11char_traitsIjESaIjEED1Ev)
I/DEBUG   (   34):          #08  pc 002b620c  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN2sf6StringD1Ev)
I/DEBUG   (   34):          #09  pc 003b8eec  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN3Gui7Labeled8SetLabelERKSs)
I/DEBUG   (   34):          #10  pc 00486974  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN3Gui5LabelC2ERKSs)
I/DEBUG   (   34):          #11  pc 003f1554  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN9__gnu_cxx13new_allocatorIN3Gui5LabelEE9constructIS2_IRSsEEEvPT_DpOT0_)
I/DEBUG   (   34):          #12  pc 003f1468  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt16allocator_traitsISaIN3Gui5LabelEEE12_S_constructIS1_IRSsEEENSt9enable_ifIXsrNS3_18__construct_helperIT_IDpT0_EEE5valueEvE4typeERS2_PS8_DpOS9_)
I/DEBUG   (   34):          #13  pc 003f1354  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt16allocator_traitsISaIN3Gui5LabelEEE9constructIS1_JRSsEEEDTcl12_S_constructfp_fp0_spcl7forwardIT0_Efp1_EEERS2_PT_DpOS6_)
I/DEBUG   (   34):          #14  pc 003f10f0  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt23_Sp_counted_ptr_inplaceIN3Gui5LabelESaIS1_ELN9__gnu_cxx12_Lock_policyE2EEC1IIRSsEEES2_DpOT_)
I/DEBUG   (   34):          #15  pc 003f0e18  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN9__gnu_cxx13new_allocatorISt23_Sp_counted_ptr_inplaceIN3Gui5LabelESaIS3_ELNS_12_Lock_policyE2EEE9constructIS6_IKS4_RSsEEEvPT_DpOT0_)
I/DEBUG   (   34):          #16  pc 003f0b78  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt16allocator_traitsISaISt23_Sp_counted_ptr_inplaceIN3Gui5LabelESaIS2_ELN9__gnu_cxx12_Lock_policyE2EEEE12_S_constructIS6_IKS3_RSsEEENSt9enable_ifIXsrNS8_18__construct_helperIT_IDpT0_EEE5valueEvE4typeERS7_PSE_DpOSF_)
I/DEBUG   (   34):          #17  pc 003f0624  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt16allocator_traitsISaISt23_Sp_counted_ptr_inplaceIN3Gui5LabelESaIS2_ELN9__gnu_cxx12_Lock_policyE2EEEE9constructIS6_JKS3_RSsEEEDTcl12_S_constructfp_fp0_spcl7forwardIT0_Efp1_EEERS7_PT_DpOSC_)
I/DEBUG   (   34):          #18  pc 003f0044  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt14__shared_countILN9__gnu_cxx12_Lock_policyE2EEC1IN3Gui5LabelESaIS5_EJRSsEEESt19_Sp_make_shared_tagPT_RKT0_DpOT1_)
I/DEBUG   (   34):          #19  pc 003ef678  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt12__shared_ptrIN3Gui5LabelELN9__gnu_cxx12_Lock_policyE2EEC1ISaIS1_EJRSsEEESt19_Sp_make_shared_tagRKT_DpOT0_)
I/DEBUG   (   34):          #20  pc 003eeb80  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZNSt10shared_ptrIN3Gui5LabelEEC1ISaIS1_EJRSsEEESt19_Sp_make_shared_tagRKT_DpOT0_)
I/DEBUG   (   34):          #21  pc 003ede24  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZSt15allocate_sharedIN3Gui5LabelESaIS1_EIRSsEESt10shared_ptrIT_ERKT0_DpOT1_)
I/DEBUG   (   34):          #22  pc 003ed5d8  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZSt11make_sharedIN3Gui5LabelEJRSsEESt10shared_ptrIT_EDpOT0_)
I/DEBUG   (   34):          #23  pc 003ecd64  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN13SceneProgress7InitGuiEv)
I/DEBUG   (   34):          #24  pc 003ec8e4  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN13SceneProgressC2Ev)
I/DEBUG   (   34):          #25  pc 00496bcc  /mnt/asec/com.familyxoft.croger_debug-1/lib/libcroger_d.so (_ZN12LoadingSceneC2Ej)
 
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 20, 2014, 08:44:51 pm
I'm continuing experiments with IDEs. Now it's Visual Studio 2013. I can share SFML solution with "vs-android" (https://code.google.com/p/vs-android/)
Next task - debugging. =)
ps Just unpack attachment to your SFML directory. Pathes in projects are relative.
upd: There were some errors in parameters, so i'll share with this solution on demand.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 22, 2014, 04:46:17 pm
There is problem with OpenAL again - crash on pressing "Home" button. Rebuilding last from openal-soft solves the problem. Hmm, it solves if openal was built on Linux, but not in Windows. =)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 28, 2014, 05:09:23 pm
Looking for reason why segmentation fault on 4.0.4 and less. I tried to use std::thread and std::mutex. And found deadlock here:

EglContext::EglContext(EglContext* shared, const ContextSettings& settings, const WindowImpl* owner, unsigned int bitsPerPixel) :
m_display (EGL_NO_DISPLAY),
m_context (EGL_NO_CONTEXT),
m_surface (EGL_NO_SURFACE),
m_config  (NULL)
{
#ifdef SFML_SYSTEM_ANDROID

    // On Android, we must save the created context
    ActivityStates* states = getActivity(NULL);
    Lock lock(states->mutex);

    states->context = this;

#endif

    // Get the intialized EGL display
    m_display = states->display; // getInitializedDisplay() - this function locks locked states->mutex
 
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 29, 2014, 07:29:15 pm
Why dlclose can be called in the very begining of the program? It looks like some library has been unloaded. It happens on Android < 4.0.4 only. I don't what's happening. No ideas. I have no hardware device with 4.0.3, by some reason i can't debug on emulator when program just started.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on September 30, 2014, 06:28:55 pm
I don't know why but now after onPause and then returning to app called ANativeActivity_onCreate.
Something like this works for me:
if (!oldStates)
        {
                // Launch the main thread

                std::thread* thread = new std::thread(&sf::priv::main, states);
                //sf::Thread* thread = new sf::Thread(sf::priv::main, states);
        //    thread->launch();

                // Wait for the main thread to be initialized
                states->mutex.lock();

                while (!states->initialized)
                {
                        states->mutex.unlock();
                        sf::sleep(sf::milliseconds(20));
                        states->mutex.lock();
                }

                states->mutex.unlock();
                // Share this state with the callback functions
                activity->instance = states;
        }
        else
        {
                states->context = oldStates->context;
                states->forwardEvent = oldStates->forwardEvent;
                states->processEvent = oldStates->processEvent;
                free(oldStates->savedState);
                delete oldStates;
                initializeMain(states);
                // Share this state with the callback functions
                activity->instance = states;
        }
 

PS Anybody works with Android SFML?  :(
Title: Re: Android and iOS ports available for testing
Post by: Sonkun on October 11, 2014, 03:25:25 pm
Hi here,

I've been very busy lately and I couldn't work work on the Android port. I'm back now and I had time this week to make progress on your issues. Will reply shortly :)
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 27, 2014, 06:26:10 pm
Hello,

I am trying to compile an SFML example on Android.

I use the android-ndk-r10b, the adt-bundle-windows-x86_64-20140702 with Qt 5.3.1 and I'm on Windows 7 Pro 64 bits.

I had no problems to compile SFML for Android.

However, when I want to run the SFML example on an AVD, I had a segfault :
(click to show/hide)

Why have I this error ? How can I resolve it ? Thanks in advance.

The SFML example :
(click to show/hide)


The .PRO file (I use qmake with QtCreator) :
(click to show/hide)


The Android Manifest File :
(click to show/hide)


P. S. : Why can't I create sf::String(const char*) ? I have read the cause is the std::locale, but how resolve it ?


If I forgot something, I can specify.


Best regards,


jd6.


P. S. 2 : I'm not english, so perhaps I made some mistakes. Do not hesitate to report me these. Thanks !

Title: Re: Android and iOS ports available for testing
Post by: Mario on October 27, 2014, 07:02:30 pm
While Android doesn't support locales, you should still be able to use std::string just fine. In fact, your locale is simply locked to "C".

A bigger problem might be your use of a wide character string. The Android NDK's support for wide character strings is still very minimal and most stuff is simply broken or not implemented.

You could try debugging your app, just use the "ndk-gdb-py" script/batch file found in the NDK dir.

What happens if you don't use the QT stuff at all? Is there any reason to include it?
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 27, 2014, 07:37:13 pm
Thanks ! :)

When I replace my old sf::String(wchar_t*) by sf::String(std::string("test")), I had an error : undefined reference to 'sf::String::String(std::string const&, std::locale const&)'. Why had I this error ? I tried sf::String(std::string("test"), std::locale("C")), but it doesn't work. How can I resolve it ?

How can I do not use wide character string ? Thanks in advance for your response.

I use Qt to get its classes which can be useful. Likewise Qt supports Android easily. But I think I will try without Qt stuff. And I will try debugging like you say ("ndk-gdb-py") when this problems will be resolved.

In any case, thanks for your response !
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 27, 2014, 07:41:33 pm
Just use "sf::String test("some text");" for now.
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 27, 2014, 07:56:16 pm
Thanks for your response ! :)

Unfortunately, it doesn't work :
main.obj:main.cpp:function main: error: undefined reference to 'sf::String::String(char const*, std::locale const&)'
collect2.exe: error: ld returned 1 exit status

The new code :
(click to show/hide)
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 27, 2014, 08:51:41 pm
This is really weird. What happens without the QT header?
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 27, 2014, 09:50:00 pm
Without "#include <QCoreApplication>", I had the same error.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on October 28, 2014, 06:57:42 am
Hm, I wanted to write that I have all ok with sf::String, but I've found that I have no any code with using of sf::String(const char*) directly. It's because I'm using LanguageManager where all text is in external lang files and sf::String returned by function that converts UTF8 source text to std::string.
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 28, 2014, 09:04:50 am
Thanks for your answer ! :)

So I will continue to use wchar_t*.

Now, I will try debugging without Qt. I keep you informed.
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 29, 2014, 11:25:31 am
I tested without Qt. I used Eclipse and ndk-build. But, I always had the segfault :
(click to show/hide)

How can I resolve this error ? Thanks in advance for your answer ! :)

AndroidManifest.xml :
(click to show/hide)

MainActivity.java :
(click to show/hide)

sfmlexample.cpp :
(click to show/hide)

Android.mk :
(click to show/hide)

I tried to use ndk-gdb-py, but I had an error :
(click to show/hide)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on October 29, 2014, 12:01:30 pm
Android SFML does not need any Java code. All inclusive! =)
Title: Re: Android and iOS ports available for testing
Post by: jd6 on October 29, 2014, 01:07:22 pm
Thanks for your answer ! :)

I tested the example like Sonkun explained, and the program works ! I will try now to develop my own game, and I hope that I will have no bugs.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on October 29, 2014, 05:54:41 pm
I hope that I will have no bugs.
Use IDDQD for it. =)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 03, 2014, 02:19:04 pm
By the way, NDK r10c released.
Quote
Made the following changes to download structure:
Each package now contains both the 32- and the 64-bit headers, libraries, and tools for its respective platform.
STL libraries with debugging info no longer need be downloaded separately.
Changed everything previously called Android-L to the official release designation: android-21.
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 16, 2014, 08:10:47 pm
Got something new for you to test. :)

CMake 3.1.0 (atm available as RC2) is now able to create project files compatible with Nvidia's Nsight Tegra extension for Visual Studio.

The changes from this commit (https://github.com/MarioLiebisch/SFML/commit/67a86849c93d9c7d76c50e2f19b5f810442c4b7d) make it possible to use the Android toolchain file and create a project for Visual Studio without further changes.

Unfortunately sfml-graphics won't build for me and I just can't find the problem (I'm obviously missing some minor detail). Linking fails due to references from sfml-window and sfml-system missing, which can't be true (since the other libraries depending on sfml-system link just fine). Order of modules/libraries on command line etc. are fine. Feel free to try it and tell me what you think is going wrong. :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 17, 2014, 02:43:40 pm
http://blogs.msdn.com/b/visualstudioalm/archive/2014/11/12/debugging-c-code-on-android-with-visual-studio-2015.aspx
Anybody tested with VS2015 preview? I think it is epic win for MS. But I've not tested yet.
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 17, 2014, 02:45:50 pm
Same can be done with Nvidia's Tegra Nsight already. :)

I don't even have to use the toolchain file to build (some minor adjustments required). Yet there's still that annoying bug that keeps sfml-graphics from linking.

Debugging SFML apps on Android/connected devices works like a charm though. :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 17, 2014, 04:29:14 pm
I didn't knew about this thing.  :o
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 17, 2014, 06:11:37 pm
Generated projects wants "-std=c++11" to compile and I corrected "-lEGL -lGLESv1_CM" to "EGL;GLESv1_CM" manually in vcproj files (VS2013CE) - my fault, bad patching. And now I have the same bug with linkage of sfml-graphics.
And there is need for variable to place libs in subdirectory by architecture.
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 18, 2014, 10:07:38 am
Hi there.
I'm currently trying to get a simple sample app to work in iOS Simulator. After the hell having to compile FreeType-lib and LibJPEG (I have no idea which versions have been compiled and committed to the repository, but the last trunk versions of these have various incompatible parts of source code), I have now have a running app based on the MacOS Sample Code for the main loop. However. The screen stays black. Trying to change the glClearColor does nothing, it stays black. Further the "[m_context presentRenderbuffer:GL_RENDERBUFFER_OES]" call inside the "EAglContext::display()"-method takes about one second. No vsynch, no frametime specified.
Any ideas?

Edit: I forgot to include SFML/Main.hpp. Then I had to remove the Storyboard-reference from Info.plist, but now my main() doesn't get called anymore at all.

Edit2: There had been no way to get CLang convinced to call my "main" (actually internally the "sfmlMain"). Seems to be a linker-issue. Currently I performed a hack I'd like to remove: I have my own correct "main", that one calls the MainiOS.mm-main (I renamed it), then it starts the Application-Delegate and calls back my sfmlMain. I have removed the function-definitions in SFMain.mm for that to work (even though they were weak). Like I said, I'd like to rather have my SFML not patched this way, but I didn't get it to work otherwise.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 19, 2014, 06:36:45 pm
Yet there's still that annoying bug that keeps sfml-graphics from linking.
I remember that I had the same problem with "vs-android". Then I removed "soname" setting and the problem was solved. But with Nsight I can't see the way to remove "soname" from command line.
But with "vs-android" there were troubles with all libraries...
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 19, 2014, 06:55:32 pm
I remember that I had the same problem with "vs-android". Then I removed "soname" setting and the problem was solved.
Hah! That did the trick. Just add -Wl,--soname= to the linker's "Command Line". Haven't tested it yet though (those libs are significantly bigger than stuff compiled with make.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 19, 2014, 07:01:41 pm
Yes, it works! =) But linker must be not "gold" - I tried it all. =)
May be this can help too - http://www.cmake.org/cmake/help/v2.8.12/cmake.html#prop_tgt:NO_SONAME
And in .vcproj I've found "<SoName>libsfml-window.so</SoName>" - removing of this does nothing without "-Wl,--soname="
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 20, 2014, 07:09:38 pm
Mario, I like NSight, thank you. I was close to buy VisualGDB. You saved my money. =)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 22, 2014, 06:50:54 pm
Is there any legal way to avoid "move" event after finger down?
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 22, 2014, 07:02:27 pm
Why would you want to prevent that? TouchBegan, Moved and Ended are basic concepts for any touch sensitive API. If you want to ignore that event, you'll have to create your own logic to stop handling it in certain circumstances.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 22, 2014, 07:10:46 pm
I don't need "move" event when I just touched the screen. I don't moved anything. I made a hack to avoid it but it is not normal behavior anyway.
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 22, 2014, 08:01:47 pm
You get a move instantly after a TouchBegan? Or you don't get a TouchBegan at all? Both sounds odd though indeed. I'd believe though that SFML isn't creating events which don't came from the OS.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on November 22, 2014, 08:13:14 pm
You get a move instantly after a TouchBegan?
Yes. And it is not SFML's bug.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 07, 2014, 12:19:18 pm
By the way, I tried static build for SFML, except sfml-activity.so, and size of APK file 20Mb instead of 28Mb now.
And I don't have ideas how to avoid use of sfml-activity.so... OS tries to load "openal" and "sndfile" and can't find them.
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 07, 2014, 12:32:32 pm
That's the tricky part discussed a few pages earlier.

Similar to your standard main() you'll need an entry point for your activity, which is in sfml-activity. Due to the way the linker works by default, this entry point won't be importet/added to the resulting binary.

You can avoid that, but you'd have to include the code of sfml-activity in your own shared library.

Not sure about your problem wrt openal/libsndfile, although I haven't tried static linking so far.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 07, 2014, 01:03:40 pm
"sfml-activity.so" has no dependencies of openal and sndfile so there are no problem to start from here and to load deps manually. But without "sfml-activity" the main object is my app:
        <meta-data android:name="android.app.lib_name" android:value="croger_d" />
And my app has dependencies from two libs - openal and sndfile. When my app succefully found then OS tries to load it. And can't load dependency of openal and sndfile - not found. But "libopenal.so" and "libsndfile.so" are in APK and registered in META-INF.
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 07, 2014, 04:17:10 pm
Ah, but not really sure what's causing this. Although something interesting to try/test.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 07, 2014, 04:43:56 pm
And the most intresting, now app runs on 4.0.3 emulator and almost runs on 2.3.3 (but can't create RenderTexture). With shared SFML libs app succesfully worked only on 4.2 real device.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 08, 2014, 08:38:54 pm
How about to make this function returning int
int InputImpl::setVirtualKeyboardVisible(bool visible)
where int is height of VK in pixels?
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 08, 2014, 08:43:00 pm
Didn't try, but shouldn't you get a resize event? Not sure right now.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 08, 2014, 08:50:06 pm
Nope, no resize event now. And latin chars only sent by sf::Event::TextEntered. =(
I'm getting AKEYCODE_UNKNOWN when trying to use russian.
    case AKEY_EVENT_ACTION_MULTIPLE:
        // Since complex inputs don't get separate key down/up events
        // both have to be faked at once
        event.type = Event::KeyPressed;
        forwardEvent(event);
        event.type = Event::KeyReleased;
        forwardEvent(event);

        // This requires some special treatment, since this might represent
        // a repetition of key presses or a complete sequence
        if (key == AKEYCODE_UNKNOWN)
        {
            // This is a unique sequence, which is not yet exposed in the NDK
            // http://code.google.com/p/android/issues/detail?id=33998
        }
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 08, 2014, 09:06:41 pm
As far as I know the NDK doesn't properly support multibyte character codes, won't change soon (unless something changes in the NDK).
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on December 21, 2014, 11:28:24 am
sf::RenderTexture -  clear({0, 0, 0, 0}); - does not work on Android 4.2. It can't fill with transparent colour, black colour works well.
Well, alpha 128 works too.

I don't know what it was, but it works now.  :o
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on February 06, 2015, 03:20:13 pm
Quote
We've just updated Nsight Tegra from version 2.0.0.14317 to version 2.0.0.15033 with the following changes:

    Fixed the soname of the built shared libraries (it was always empty)
    Fixed hangs/timeout issues some of the users were experiencing during the debug launch process
    Fixed inability to merge normal archives into a thin archive
    Fixed gdbserver uploading/choosing mechanism to continue if one of the steps throws an exception


This release is not a part of TADP3.0r4 and should be downloaded and installed manually: https://developer.nvidia.com/gameworksdownload#?dn=nsight-tegra-visual-studio-edition-2-0-refresh
https://devtalk.nvidia.com/default/topic/612548/nsight-tegra-visual-studio-edition/nsight-tegra-fixes-since-release-check-here-to-see-if-your-bug-has-been-fixed-/
Title: Re: Android and iOS ports available for testing
Post by: AlexxanderX on February 07, 2015, 09:24:34 am
I need some help please: I receive when I run in a virtual device( API 15) the example provided:
Quote
627-627/com.example.sfml A/libc﹕ Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1)
I'm using ndk-r10d.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on February 07, 2015, 09:32:34 am
If this is the thing what I think, so I solved this problem by compiling against static SFML. And application can work with API-9 too.
Title: Re: Android and iOS ports available for testing
Post by: AlexxanderX on February 07, 2015, 10:06:32 am
I use API 15 because is the same with my phone.
I have built with -DBUILD_SHARED_LIBS=0, but same error. I think I still need to edit some files in the example, but don't know where.
Title: Re: Android and iOS ports available for testing
Post by: Mario on February 07, 2015, 10:21:57 am
Quote
We've just updated Nsight Tegra from version 2.0.0.14317 to version 2.0.0.15033 with the following changes:

    Fixed the soname of the built shared libraries (it was always empty)
    Fixed hangs/timeout issues some of the users were experiencing during the debug launch process
    Fixed inability to merge normal archives into a thin archive
    Fixed gdbserver uploading/choosing mechanism to continue if one of the steps throws an exception


This release is not a part of TADP3.0r4 and should be downloaded and installed manually: https://developer.nvidia.com/gameworksdownload#?dn=nsight-tegra-visual-studio-edition-2-0-refresh
https://devtalk.nvidia.com/default/topic/612548/nsight-tegra-visual-studio-edition/nsight-tegra-fixes-since-release-check-here-to-see-if-your-bug-has-been-fixed-/

Aaaargh! :D

All that time I wasted trying to determine why linking of sfml-graphics would always fail when not using the extra toolchain file!

But now...

Good news, everyone! It's now possible to compile SFML for Android utilizing Visual Studio and Nvidia's Nsight Tegra VS Edition alone. It's no longer necessary to bother using the toolchain file for CMake if you've got Windows. :)

Now we just need some more testing (everyone invited having the proper system for this), since I'd like to merge those changes as soon as possible (for further improvements not directly related, like being able to pick a STL implementation):

Next Steps
(Open for suggestions)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on February 07, 2015, 12:11:58 pm
I use API 15 because is the same with my phone.
I have built with -DBUILD_SHARED_LIBS=0, but same error. I think I still need to edit some files in the example, but don't know where.
You can't just build static Android SFML. I made some changes in code and I used Tegra-Android to build it. https://bitbucket.org/SteelRat/gipe/src/711aa6630f0db3f277c4484ffc15f99051d368a3/deps/sfml/?at=default = there you can see what I done.
Title: Re: Android and iOS ports available for testing
Post by: Crynux on February 17, 2015, 07:11:47 am
I've been trying for the past few days to access a Java class from Android SFML. So far, I've tried to get access to JavaVM and/or JNIEnv, but for some reason it cannot find my Java class (It's in the apk and such).

My goal is to use SFML for graphics, but I have an Android library that I'm using which requires the use of Java.

Anyone have any pointers for how/where to call a Method from a Java class using SFML for Android? Or is it not possible at this point?

Thanks in advance for any help.
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on February 17, 2015, 07:26:03 am
Wouldn't it typically be the other way round? You write a Java-App and access some C++ native code via JNI from Java?
Title: Re: Android and iOS ports available for testing
Post by: Crynux on February 17, 2015, 07:49:30 am
Yeah, I was thinking that too, but if going from a Java standpoint, I don't know how to get SFML running on a Java-based Activity. I've tried a few things, but no luck. So at this point I'm assuming that for SFML, you'd have to call Java from the C/C++ code.
Title: Re: Android and iOS ports available for testing
Post by: Mario on February 17, 2015, 08:46:54 am
Yep, it's not really made for that purpose (so far).

You can look into the Android specific code of SFML (src/SFML/window/Android) to see how you can call Java stuff from C++, although it's quite tricky and anything but clean.

I thought about creating an easier wrapper class to call Java stuff as an extension (not core SFML), but lack of time and too many other things to work on first.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on February 17, 2015, 09:01:52 am
Quote
I thought about creating an easier wrapper class to call Java stuff as an extension (not core SFML), but lack of time and too many other things to work on first.
I think Qt could be a good source for inspiration. They have solutions for both ways:
- they have a QtAndroidExtra module (http://doc.qt.io/qt-5/qtandroidextras-index.html) for Android, with a few useful wrappers like QAndroidJniObject (http://doc.qt.io/qt-5/qandroidjniobject.html)
- you can have a "Android sources" directory with all the native Java stuff that you need: a custom manifest, resources, Java source code, etc. (see "how to deploy on Android (http://doc.qt.io/qt-5/deployment-android.html)"); this directory will be put into your final apk (and stuff that you don't define yourself will of course be generated automatically)
Title: Re: Android and iOS ports available for testing
Post by: Crynux on February 17, 2015, 09:04:36 am
Yep, it's not really made for that purpose (so far).

You can look into the Android specific code of SFML (src/SFML/window/Android) to see how you can call Java stuff from C++, although it's quite tricky and anything but clean.

I thought about creating an easier wrapper class to call Java stuff as an extension (not core SFML), but lack of time and too many other things to work on first.

Hmmm, I see.

I've tried a few things with the aim of executing some Java code, but so far it seems that either my Java .Class files aren't being loaded, or the Java VM handle/pointer/thing I get just doesn't know where they are. Any ideas? I've tried accessing the VM before the main function is called in MainAndroid.cpp [in void* main(ActivityStates* states)].

The .class files are in the .apk... I just don't know at what point they are loaded (or if they are loaded), and where that is in relation to the SFML entry point.
Title: Re: Android and iOS ports available for testing
Post by: Mario on February 17, 2015, 09:08:37 am
No idea, haven't really dabbled into that so far. What happens if you define a second (dummy) Java activity that references that code?
Title: Re: Android and iOS ports available for testing
Post by: Crynux on February 17, 2015, 09:37:19 am
Had to make sure that in the AndroidManifest.xml,  android:hasCode="true"

Once that is set, the .class files are available, and I can access them through JNI!
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 05, 2015, 06:25:21 pm
Hey guys! I finally managed to build and make SFML work on my phone(that is some really amazing stuff), but I still have one major problem - the audio ain't working. Loading from file returns message that the file isn't supported, and loading from stream(example from page) just... does nothing. Well it works perfectly on my PC after dropping libsndfile-1.dll and openal32.dll into assets, but how to make it work on Android?
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 05, 2015, 07:12:05 pm
I think there are still a few unmerged bugfixes for audio stuff (not 100% sure right now), but basic handling should work - using the default functions you're restricted to assets inside the APK though.

Have you tried the SFML example for Android?
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on April 05, 2015, 07:25:24 pm
Audio on mobile devices is not included in the 2.2 download version. It is available in the master-version from github though. Although I'm not entirely sure about this on Android, on iOS however libsndfile was not allowed to be linked statically which resulted in the iOS version to be without any sound support at all.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 05, 2015, 08:52:16 pm
Well, I built everything with the official instructions, from the newest master version and used the android example as a base. There was sound file and music with that example, none of them worked.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 06, 2015, 03:49:19 pm
Any more details you can provide? Like your NDK revision, your target NDK/API level, target SDK level, etc.?
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 12, 2015, 12:42:23 am
Thanks for Your responses. I'm using newest NDK avaible(r10d), 4.4.2(19) as a target, 9 as min(I guess that's standard config from example), nothing fancy. Also - sometimes the SFML window just don't get open - app stucks on the default theme background; sometimes it even crashes whole android. Any ideas?
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 12, 2015, 08:32:29 am
Not right now. What Android version does it crash on? Any logcat output you can share?
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 12, 2015, 09:38:16 am
Yeah, well it shows some "Failed to activate window's context" and "called unimplemented OpenGL ES API"(even when it works just fine). It usually crashes when i close my app and try to run it again in short period of time. And sound is still not working ;p

I'm using my device(Samsung Galaxy SIII with Android 4.1.2(16) directly by usb cable. Even tried downgrading target level to 16, but I guess it doesn't even make any sense to do so.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 12, 2015, 09:46:03 am
Which "unimplemented OpenGL ES API"? Any more details? The context errors/warnings are fine.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 12, 2015, 10:05:02 am
How can I check it? It doesn't say in the LogCat.

BTW I'm getting "Fatal signal 11 (SIGSEGV) at 0x00000028 (code=1), thread 26308" when I close the app.
Title: Re: Android and iOS ports available for testing
Post by: Mario on April 12, 2015, 10:30:24 am
Those might all be related in some way, we're still talking about SFML's example app?
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on April 12, 2015, 10:44:21 am
Yep, nothing changed over here.
Title: Re: Android and iOS ports available for testing
Post by: AlexxanderX on May 11, 2015, 07:29:59 pm
Now I'm getting beside the sigsegv these errors:
Quote
05-11 20:26:11.019    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.019    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.029    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.029    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.039    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.039    4777-4792/com.example.sfml I/sfml-error﹕ Failed to activate the window's context
05-11 20:26:11.039    4777-4792/com.example.sfml I/sfml-error﹕ Failed to activate the window's context
05-11 20:26:11.079    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.079    4777-4792/com.example.sfml E/Adreno200-ES20﹕ <get_simple_queries:1021>: GL_INVALID_ENUM
05-11 20:26:11.089    4777-4792/com.example.sfml E/Adreno200-ES11﹕ <qglDrvAPI_glTexImage2D:1913>: GL_INVALID_ENUM
05-11 20:26:11.089    4777-4792/com.example.sfml E/Adreno200-ES11﹕ <qglDrvAPI_glTexSubImage2D:2055>: GL_INVALID_ENUM
05-11 20:26:11.109    4777-4792/com.example.sfml E/ExtendedExtractor﹕ Failed to open MM_PARSER_LIB, dlerror = Cannot load library: reloc_library[1314]:   129 cannot locate '_ZN7android11MediaSource13getBufferInfoERNS_2spINS_7IMemoryEEEPj'...
05-11 20:26:11.109    4777-4792/com.example.sfml E/ExtendedExtractor﹕ Failed to open MM_PARSER_LITE_LIB, dlerror = Cannot load library: load_library[1120]: Library 'libmmparser_lite.so' not found
05-11 20:26:11.119    4777-4792/com.example.sfml I/sfml-error﹕ Failed to open sound file "canary.wav" (format not supported)
( errors are from the example, only changed the android-9 to android-15( and also in the manifest) and targetSdkVersion to 22.)
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 11, 2015, 07:46:59 pm
Haven't had any time to build or test the library lately, hopefully will be able to do so later this week (along with finally trying to fix some of the open issues). Which version were you using? Latest master? If not (or even if so), which revision/commit?
Title: Re: Android and iOS ports available for testing
Post by: AlexxanderX on May 11, 2015, 08:00:58 pm
Lastest master, 80214d1cb916ae5f49c63ade4c167369faab9b9e .
Title: Re: Android and iOS ports available for testing
Post by: dontworry on May 12, 2015, 04:29:28 am
I'm also getting this error trying to run the example on a virtual android device.

05-11 22:12:43.950: E/libEGL(863): called unimplemented OpenGL ES API

I'm running archlinux and have the 32-bit and the regular libEGL library. The app doesn't crash and it seems to work fine except that the image is a white square.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 12, 2015, 10:03:26 am
So just tried on my Nexus 5. Except being unable to load the canary.wav file, the app runs fine. Maybe it has to do with Android 4.x...

Could you try applying the following commit, then recompiling everything and trying again?

https://github.com/fizixx/SFML/commit/39e8d5fd611c91674e0bf2219153676e2f0dc730

This might  fix some of the sigsegs, but probably won't change anything regarding the EGL error.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 12, 2015, 10:29:28 am
Identified the sound loading issue, which might also cause the sigsegv... still not sure how that got in there.

Edit/Update:

Please test this commit:

https://github.com/SFML/SFML/commit/4284332b75b4e4b7d0061022bbc0430e0810b297

And comment in this pull request:

https://github.com/SFML/SFML/pull/887
Title: Re: Android and iOS ports available for testing
Post by: R23MJ on May 20, 2015, 07:53:24 pm
I have searched around a bit and can't find anything, so I'll ask here. I'm not sure how to build an app with the android version, I downloaded and built it and everything, but I'm not sure what project type to build (I'm using VS13 with the NVIDIA Tegra thing) do I build an android project or a C++ project? Also, how do I link the .so files, the same as usual? I tried on an android project but got somewhere around 107 errors, the top ones said that the .so files (libsfml-activity.so etc.) didn't exist.

Is there a project setup tutorial around here anywhere? Thanks.
Title: Re: Android and iOS ports available for testing
Post by: AlexxanderX on May 22, 2015, 07:24:13 am
After you compiled SFML for Android( here (https://github.com/SFML/SFML/wiki/Tutorial%3A-Building-SFML-for-Android)) just go in the folder of the sfml example and run ndk-build and then open normally the project in Eclipse or Android Studio.
Title: Re: Android and iOS ports available for testing
Post by: AlexAUT on May 22, 2015, 09:20:30 am
Project setup is very easy, you just select in eclipse-adt "Android porject with exisiting source", then navigate to the SFML directory, examples, android. Then you can check the checkbox beneath something like "copy project into workspace" so you won't modify the SFML-android example for future projects.

(I'm not quite sure, Kroniax-android is a long time ago  ;), but I think you have to add native support to your project, rightclick on the project->android tools->Add Native support.


(I haven't seen the respone from AlexxanderX, before I posted this  ::) )

AlexAUT
Title: Re: Android and iOS ports available for testing
Post by: dontworry on May 23, 2015, 11:12:37 pm
Any news on the other bug I was having?

05-11 22:12:43.950: E/libEGL(863): called unimplemented OpenGL ES API
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 24, 2015, 11:03:57 am
Not yet, some lack of time and still have to find out whether I'm actually able to reproduce it. Are there any other logcat lines nearby that might be related?
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on May 28, 2015, 08:35:54 am
About WindowImplAndroid::getUnicode.
There new Java object is created and I think it can cause Java stackoverflow without delete of local reference.
Add    lJNIEnv->DeleteLocalRef(ObjectKeyEvent); before detach of Java thread.
You have to delete local refs manually for all created Java objects, even strings.
Title: Re: Android and iOS ports available for testing
Post by: Mario on May 28, 2015, 09:01:24 am
Yeah, there are quite a few never freed Java objects anyway. Haven't read too deep into it, but I'm aware that those are most likely not freed right now.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on May 28, 2015, 09:25:07 am
I just started to work hard with JNI at my job two monthes ago. =) Btw, it is useful to create RAII class to attach Java thread (so we need JavaVM only, pointer to JNIEnv we'll receive after attaching to the thread). And check for exceptions after retreiving of method ids or classes.
I use macros for it:
#define JAVA_EXCEPTION_CHECK_AND_DO(env, doNext)\
                if (env->ExceptionCheck())\
                {\
                        jthrowable throwable = env->ExceptionOccurred();\
                        if (throwable != NULL)\
                        {\
                                Java::LogException(env, throwable);\
                                doNext;\
                        }\
                }
This allow us to not to crash each time if something goes wrong with Java.

Class for attach to Java thread:

namespace Java
{

class Thread
{
public:

        explicit Thread();
        explicit Thread(JavaVM* jvm, JNIEnv*& env);
        ~Thread();

        void Attach(JavaVM* jvm, JNIEnv*& env);
        void Detach();
        bool IsAttached() const { return m_Attached; }

private:

        bool            m_Attached;
        JavaVM*         m_JavaVM;
};

} // namespace Java
 

Implementation:
namespace Java
{

Thread::Thread():
        m_Attached(false),
        m_JavaVM(NULL)
{
}



Thread::Thread(JavaVM* jvm, JNIEnv*& env):
        m_Attached(false),
        m_JavaVM(NULL)
{
        Attach(jvm, env);
}



void Thread::Attach(JavaVM* jvm, JNIEnv*& env)
{
        assert(jvm);
        assert(!m_Attached && "Must be detached before call this function!");
        m_JavaVM = jvm;
        int status = m_JavaVM->GetEnv((void **)&env, JNI_VERSION_1_6);

        if (status == JNI_EDETACHED)
        {
                jint res = m_JavaVM->AttachCurrentThread(&env, NULL);
                m_Attached = res == JNI_OK;
        }
}



Thread::~Thread()
{
        Detach();
}



void Thread::Detach()
{
        if (m_Attached)
        {
                m_Attached = false;
                jint res = m_JavaVM->DetachCurrentThread();
                assert(res == 0);
        }
}

} // namespace Java
 

Using:
JNIEnv* env = NULL;
Java::Thread attach(m_JavaVM, env);
env->FindClass(....
 
And we don't bother where to exit from the function.

And another one note: use variables to hold method ids or java classes. It will improve performance greatly.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on May 28, 2015, 11:28:11 am
For example, how to use JNI a little bit faster and much more safer or vice versa =) (based on SFML "setVirtualKeyboardVisible"):
#ifndef _ANDROID_VIRTUAL_KEYBOARD_H_
#define _ANDROID_VIRTUAL_KEYBOARD_H_



#include <jni.h>



class VirtualKeyboard
{
public:
        VirtualKeyboard();
        explicit VirtualKeyboard(JavaVM* vm, jobject activityObject);
        ~VirtualKeyboard();

        void Init(JavaVM* vm, jobject activityObject);
        bool SetVisible(bool b) const;
        int GetUnicodeValue(int deviceId, int keyCode, int meta) const;

private:

        void Clear();

        JavaVM*         m_JavaVM;
        jobject         m_InputMethodManager;
        jobject         m_DecorView;
        jclass          m_KeyCharacterMapClass;
        jmethodID       m_HideSoftInput;
        jmethodID       m_ShowSoftInput;
        jmethodID       m_GetWindowToken;
        jmethodID       m_LoadKeyMap;
        jmethodID       m_KeyMapGet;
};


#endif // _ANDROID_VIRTUAL_KEYBOARD_H_
 

Implementation:

#include "virtual_keyboard.h"
#include <android/native_activity.h>



static const char* CONTEXT_PATH = "android/content/Context";
static const char* INPUT_METHOD_MANAGER_PATH = "android/view/inputmethod/InputMethodManager";
static const char* WINDOW_PATH = "android/view/Window";
static const char* VIEW_PATH = "android/view/View";
static const char* KEY_CHARACTER_MAP_PATH = "android/view/KeyCharacterMap";



VirtualKeyboard::VirtualKeyboard():
        m_JavaVM(NULL),
        m_InputMethodManager(NULL),
        m_DecorView(NULL),
        m_KeyCharacterMapClass(NULL),
        m_HideSoftInput(0),
        m_ShowSoftInput(0),
        m_GetWindowToken(0),
        m_LoadKeyMap(0),
        m_KeyMapGet(0)
{
}



VirtualKeyboard::VirtualKeyboard(JavaVM* vm, jobject activityObject):
        m_JavaVM(NULL),
        m_InputMethodManager(NULL),
        m_DecorView(NULL),
        m_KeyCharacterMapClass(NULL),
        m_HideSoftInput(0),
        m_ShowSoftInput(0),
        m_GetWindowToken(0),
        m_LoadKeyMap(0),
        m_KeyMapGet(0)
{
        Init(vm, activityObject);
}



VirtualKeyboard::~VirtualKeyboard()
{
        Clear();
}



void VirtualKeyboard::Clear()
{
        if (!m_JavaVM)
        {
                return;
        }

        JNIEnv* env = NULL;
        Java::Thread attach(m_JavaVM, env);
        env->DeleteWeakGlobalRef(m_InputMethodManager);
        env->DeleteWeakGlobalRef(m_DecorView);
        env->DeleteWeakGlobalRef(m_KeyCharacterMapClass);
        m_JavaVM = NULL;
        m_InputMethodManager = NULL;
        m_DecorView = NULL;
        m_KeyCharacterMapClass = NULL;
        m_HideSoftInput = 0;
        m_ShowSoftInput = 0;
        m_GetWindowToken = 0;
        m_LoadKeyMap = 0;
        m_KeyMapGet = 0;
}



void VirtualKeyboard::Init(JavaVM* vm, jobject activityObject)
{
        if (m_JavaVM)
        {
                Clear();
        }

        if (!vm || !activityObject)
        {
                return;
        }

        m_JavaVM = vm;
        JNIEnv* env = NULL;
        Java::Thread attach(m_JavaVM, env);
        jclass activityClass = env->GetObjectClass(activityObject);
        jclass contextClass = env->FindClass(CONTEXT_PATH);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jfieldID fieldINPUT_METHOD_SERVICE = env->GetStaticFieldID(contextClass,
                "INPUT_METHOD_SERVICE", "Ljava/lang/String;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jobject INPUT_METHOD_SERVICE = env->GetStaticObjectField(contextClass,
                fieldINPUT_METHOD_SERVICE);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(contextClass);

        jclass inputMethodManagerClass =
                env->FindClass(INPUT_METHOD_MANAGER_PATH);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jmethodID getSystemServiceMethod = env->GetMethodID(activityClass,
                "getSystemService", "(Ljava/lang/String;)Ljava/lang/Object;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jobject inputMethodManagerObject = env->CallObjectMethod(activityObject,
                getSystemServiceMethod, INPUT_METHOD_SERVICE);
        env->DeleteLocalRef(INPUT_METHOD_SERVICE);

        jmethodID getWindowMethod = env->GetMethodID(activityClass,
                "getWindow", "()Landroid/view/Window;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(activityClass);

        jobject windowObject = env->CallObjectMethod(activityObject, getWindowMethod);

        jclass windowClass = env->FindClass(WINDOW_PATH);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jmethodID getDecorViewMethod = env->GetMethodID(windowClass,
                "getDecorView", "()Landroid/view/View;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(windowClass);

        jobject decorViewObject = env->CallObjectMethod(windowObject, getDecorViewMethod);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(windowObject);

        jmethodID showSoftInputMethod = env->GetMethodID(inputMethodManagerClass,
                "showSoftInput", "(Landroid/view/View;I)Z");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jclass viewClass = env->FindClass(VIEW_PATH);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jmethodID getWindowTokenMethod = env->GetMethodID(viewClass,
                "getWindowToken", "()Landroid/os/IBinder;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(viewClass);

        jmethodID hideSoftInputMethod = env->GetMethodID(inputMethodManagerClass,
                "hideSoftInputFromWindow", "(Landroid/os/IBinder;I)Z");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);
        env->DeleteLocalRef(inputMethodManagerClass);

        jclass keyCharacterMapClass = env->FindClass(KEY_CHARACTER_MAP_PATH);
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jmethodID loadMethod = env->GetStaticMethodID(keyCharacterMapClass,
                "load", "(I)Landroid/view/KeyCharacterMap;");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        jmethodID getMethod = env->GetMethodID(keyCharacterMapClass,
                "get", "(II)I");
        JAVA_EXCEPTION_CHECK_AND_DO(env, m_JavaVM = NULL; return);

        m_InputMethodManager = env->NewWeakGlobalRef(inputMethodManagerObject);
        env->DeleteLocalRef(inputMethodManagerObject);
        m_DecorView = env->NewWeakGlobalRef(decorViewObject);
        env->DeleteLocalRef(decorViewObject);
        m_KeyCharacterMapClass = (jclass) env->NewWeakGlobalRef(keyCharacterMapClass);
        env->DeleteLocalRef(keyCharacterMapClass);
        m_HideSoftInput = hideSoftInputMethod;
        m_ShowSoftInput = showSoftInputMethod;
        m_GetWindowToken = getWindowTokenMethod;
        m_LoadKeyMap = loadMethod;
        m_KeyMapGet = getMethod;
}



bool VirtualKeyboard::SetVisible(bool b) const
{
        if (!m_JavaVM)
        {
                return false;
        }
        JNIEnv* env = NULL;
        Java::Thread attach(m_JavaVM, env);
        bool res = false;
        int flags = 0;

        if (b)
        {
                res = env->CallBooleanMethod(m_InputMethodManager,
                        m_ShowSoftInput, m_DecorView, flags);
        }
        else
        {
                jobject binderObject = env->CallObjectMethod(m_DecorView,
                        m_GetWindowToken);
                res = env->CallBooleanMethod(m_InputMethodManager,
                        m_HideSoftInput, binderObject, flags);
                env->DeleteLocalRef(binderObject);
        }
        return res;
}



int VirtualKeyboard::GetUnicodeValue(int deviceId, int keyCode, int meta) const
{
        if (!m_JavaVM || keyCode == 0)
        {
                return 0;
        }
        JNIEnv* env = NULL;
        Java::Thread attach(m_JavaVM, env);
        jobject kcmObject = env->CallStaticObjectMethod(m_KeyCharacterMapClass, m_LoadKeyMap, deviceId);
        JAVA_EXCEPTION_CHECK_CONTINUE(env);

        if (!kcmObject)
        {
                return 0;
        }

        int unicode = env->CallIntMethod(kcmObject, m_KeyMapGet, keyCode, meta);
        JAVA_EXCEPTION_CHECK_CONTINUE(env);
        env->DeleteLocalRef(kcmObject);
        return unicode;
}

 

And you have to call Init function each time "ANativeActivity_onCreate" called.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on May 28, 2015, 01:40:51 pm
About this part of code:
        // This requires some special treatment, since this might represent
        // a repetition of key presses or a complete sequence
        if (key == AKEYCODE_UNKNOWN)
        {
            // This is a unique sequence, which is not yet exposed in the NDK
            // http://code.google.com/p/android/issues/detail?id=33998
        }
 
In this case you have to return value as Unhandled event. This will allow to catch this event in Java and use "KeyEvent.getCharacters" method. Now your "handled" variable is always set to 1, and user can't catch this event in "dispatchEvent" method.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on May 31, 2015, 09:20:50 pm
Btw, object returned by (JNIEnv) GetObjectClass requires to delete local ref to it after use. Or you can get this error: "E dalvikvm: JNI ERROR (app bug): local reference table overflow (max=512)"
I just ran stress-test for previously posted VirtualKeyboard to initialize it per frame. So, we need to delete local reference to EVERY jobject (jclass, jstring, jarray) - CallObjectMethod, GetObjectClass, FindClass... for all of them.
I updated post with VirtualKeyboard class. There are fixed leaks of local refs. Pay attention to other way to get unicode value. I think it is better (no proofs =)).
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 04, 2015, 05:00:57 pm
Yeah, those references... wanted to have a look at them for a long time now.

I've created a new commit/branch here: https://github.com/SFML/SFML/commit/40248b65c309c5b95e57dd4c21f74668be89b4da

Would be great if you could have a look, since I'm not really familiar with the different reference types (local vs. global vs. weak global).

This also fixes the unhandled input event.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on June 05, 2015, 08:12:22 am
Well, local reference will be broken as only you detach from the thread, but it is required to be deleted before detach anyway.
Weak global is good to transfer object through several functions where Java thread attached/dettached several times. I did stress-test for it, and most weak references were active whole app runtime, but one of them was broken after 1000-1500 cycles. So, it is bad to hold them whole app lifecycle, nobody knows when it will become broken.
And global reference is reliable and good to hold never changing objects. So, it is better to use in previously posted VirtualKeyboard class, for example.
I hadn't notice change of JavaVM pointer in "ANativeActivity_onCreate", I don't know how constant this value is. Sure, it is good idea to reinit all Java RAII objects in the case if activity->vm will be changed.
About code - looks like you go in the right way. =)
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 05, 2015, 08:22:23 am
Don't think the JVM ever changes while the app is running (would be odd IMO), so I'm still toying with the idea of just having one static "JavaEnvironment" class or something like that handling all the references, lifetime, etc.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on June 05, 2015, 08:31:51 am
Is it possible to use more than one Java VM in the app? I don't know why. =) Well, I think that static "JavaEnvironment" is good enough if there is only one JVM.
Title: Re: Android and iOS ports available for testing
Post by: victorlevasseur on June 07, 2015, 10:08:46 am
I've built SFML for Android and I get a "Failed to activate window's context" error when I launch the "android" example inside my Nexus 7 2013. Do you have an idea about what's wrong ?
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 07, 2015, 10:15:08 am
That "error" is completely fine. Right now you should get it a few times till your app is actually shown on screen. If your app doesn't show up, gets stuck or crashes, the issue is mostl ikely some other line in your logcat output.
Title: Re: Android and iOS ports available for testing
Post by: victorlevasseur on June 07, 2015, 10:25:38 am
Thanks for your answer. Nothing shows on the screen (except the app title and the default background color). But I see an error coming from the "canary.wav". So I removed the lines playing the sound and it works perfectly.
Title: Re: Android and iOS ports available for testing
Post by: Mario on June 07, 2015, 11:52:29 am
It's a bug with sound loading in 2.3, see a few pages ago. There's a branch and pull request on GitHub if you'd like to try a fix.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on July 22, 2015, 01:19:28 pm
Btw, to get unicode (non-english, while it's impossible in pure NDK) value use Java:
public class AppActivity extends NativeActivity
{
        // transfer unicode value to C++
        public static native void UnicodeValueCPP(int value);

        // we are using this to catch non-ascii chars (yes, it is impossible in NDK)
        @Override
        public boolean dispatchKeyEvent(KeyEvent event)
        {
                String chars = event.getCharacters();

                if (chars != null && !chars.isEmpty())
                {
                        UnicodeValueCPP(chars.codePointAt(0));
                }
                return super.dispatchKeyEvent(event);
        }
};
 
You just need to change in manifest file android.app.NativeActivity to .AppActivity.
Title: Re: Android and iOS ports available for testing
Post by: Mario on July 22, 2015, 03:54:19 pm
Yeah, well, only problem, there's no Java code in SFML (it's a 100% native activity). Not sure this event can somehow be overridden.
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on July 22, 2015, 04:10:34 pm
But SFML has NativeActivty. This method overrides it. Be sure, I tested it before posting here. =) You have to create subfolder 'src/com/company/application', AppActivity.java there - and it will work. Especially it can be easily done with nVidia AndroidWorks.
upd: Well, I'm not 100% sure about String method 'codeAtPoint', but the string value of getCharacters is absolutly correct - it contains unicode char of pressed key.
Title: Re: Android and iOS ports available for testing
Post by: Mario on July 22, 2015, 05:59:27 pm
Okay, so you can still override those despite explicitly using the native activity? That's interesting, although an ugly workaround. Maybe it's possible to inject the code at runtime. :)
Title: Re: Android and iOS ports available for testing
Post by: ChronicRat on July 22, 2015, 09:24:11 pm
Maybe it's possible to inject the code at runtime. :)
I think it's possible.
https://community.oracle.com/thread/2298550
Title: Re: Android and iOS ports available for testing
Post by: zmertens on August 02, 2015, 01:29:10 am
I'm interested in learning how to set up the SFML for Android build. I'm using the tutorial from the wiki and I ran into an error while running cmake:

(click to show/hide)

I checked and double checked my PATH variables to see that they pointed to the Android SDK directories and NDK. My directories are set up like /example/SFML/ and then /example/SFML-build-mobile and I am using CMake-GUI.
I have been able to run SDL's sample android project so I 'm sure ndk-build is working at least for that project.

I'm using CMake 2.8.12.2, Linux Mint 17.2, and I'm building off the SFML master branch (26fc872844) if that helps any.

-- An idea just popped into my head, do I need a specific Android SDK API level? I only have 18 and 21 or 22 right now.
Title: Re: Android and iOS ports available for testing
Post by: Mario on August 02, 2015, 09:45:41 am
CMake won't check your PATH environment variable for cross-compiling (bad things might happen!). Instead you have to set ANDROID_NDK to point there (or pass it as a CMake variable).
Title: Re: Android and iOS ports available for testing
Post by: zmertens on August 02, 2015, 09:41:55 pm
Well, I got it all figured it out and I got the example program running on my phone using Android Studio (My phone is a LGL41C with Android version 4.4.2). I had to create the project manually in Android Studio which was not hard at all since I had played around with the NDK already. I couldn't import the SFML android example though because Gradle couldn't be configured from the project, so I just copied everything over by hand. I also added the JNI stuff to my app build.gradle file so it looks like this:

(click to show/hide)

I followed information from this Stack Overflow Q (http://stackoverflow.com/questions/16667903/android-studio-gradle-and-ndk)

I couldn't hear any sound from the example but I was able to move the icon around with my hand. I hope to play around with it more later on.

I am getting spammed about an error: "Failed to activate window's context" which I think I have seen mentioned here already several times and not to worry about it.

Last, I have a quick CMake question. Is there some way I can use CMake-GUI to build the libraries (armeabi, mips, etc)? I tried to by adding the variables that I normally would use from command line and it couldn't seem to figure out I wanted Android and not desktop SFML, so I'm probably not adding the right variables. I had no issues using the command line CMake from the example (https://github.com/SFML/SFML/wiki/Tutorial%3A-Building-SFML-for-Android) after following Mario's suggestion above.

Title: Re: Android and iOS ports available for testing
Post by: Mario on August 03, 2015, 12:07:13 am
I'm usually using a small batch file to build and install all architectures at once, I'm sure you can use that to figure out the correct parameters:

@echo off
set ANDROID_NDK=E:/Android/NDK
set ANDROID_SDK=E:/Android
for /D %%D in (*.) do (cd %%D && (mingw32-make install || (cmake -G "MinGW Makefiles" -DCMAKE_TOOLCHAIN_FILE=../../../cmake/toolchains/android.toolchain.cmake -DANDROID_ABI=%%D -DANDROID_API_MIN=9 -DCMAKE_BUILD_TYPE=Release -DANDROID_STL=c++_shared ../../.. && mingw32-make install)) && cd ..)

This obviously only works for Windows, but you can do similar things on other systems.

What this does is compiling all architectures identified by the name of the sub folders right next to this script. E.g. to build "armeabi" and "x86" I just create two folders with those names and run it.
Title: Re: Android and iOS ports available for testing
Post by: Kori on October 13, 2015, 10:48:00 am
Excellent work, until now everything works fine. Only i don't know how to hide navigation bar (this on bottom) on tablet devices. Anyone help?
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 13, 2015, 11:02:17 am
It should auto-hide on its own, if you request a window with sf::Style::Fullscreen, which should activate immersive mode, if available (Android 4.x and higher).
Title: Re: Android and iOS ports available for testing
Post by: Kori on October 13, 2015, 11:37:02 am
I'm testing it on android 4.4.2. On newer (5.x) or older (2.3.3) with physical button it's working.
Adding sf::Style::Fullscreen doing nothing.
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 14, 2015, 11:52:49 am
I read that SFML works on Android & Ios from v2.2

This is the only thread I could find on the subject.

Is android & ios support support still in the early experimental stages, or everything works?

Why are there no ready-made compiled libs to download like for Windows?

Thanks
Title: Re: Android and iOS ports available for testing
Post by: Nexus on October 14, 2015, 12:19:21 pm
Yes, support for mobile platforms is still experimental.
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 14, 2015, 12:21:39 pm
thanks for the info.

is there any resources or information yet for this experimental support, especially for ios?
Title: Re: Android and iOS ports available for testing
Post by: Nexus on October 14, 2015, 12:29:53 pm
iOSAndroid
You'll certainly find more if you search in the forum. It would be great if you helped merge the spread information, maybe in a Wiki article.
Title: Re: Android and iOS ports available for testing
Post by: xGEKKOx on October 14, 2015, 03:09:43 pm
Hi all,

first of all i want to say sorry for my bad english, i'm italian and i always try to do my best...

i'm Gekko and i just registered on SFML forum after my friend BJAdams suggested to me.
Like BJ i come from another engine that i used to publish all my apps (120 at the moment, all on Apple devices).

Many of them are top sellers and i will always be thankful to them as that engine changed my life.
But now the things are changing, i reached a bigger level and i need a better 2D engine that follow what a "successful" developer need.

I don't want to talk of that engine, but i'm here to give my knowledge on iOS/MAC/tvOS/Watch for free.
I understand you don't know me, but give me a possibility.

I have all the devices from Apple, including the tvOS Developer Kit, as they always take me in consideration for the earning i carry them.

My kind of coding is C++ mixed with OBJC and my friend BJ said that SFML is C++ but need some support on Apple side.

Now i will give a look to the SFML test for iOS to get an idea and wait for some reply here.

I will try to have a working test and i will post something when done, while wait for an Admin reply :D

I hope i will be usefull to the community...
So... here i am :D
Title: Re: Android and iOS ports available for testing
Post by: Hiura on October 15, 2015, 10:35:03 am
BJ said that SFML is C++ but need some support on Apple side.

Yep, that's true. Mainly for testing on OS X (bug report and so on). The iOS port was not, as far as I know, used a lot so if you have feedback on that one it's highly welcome.

You can find out how we work here and how to contribute (http://www.sfml-dev.org/development.php).  ;)
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 17, 2015, 07:40:49 pm
The exposed Native Activity handle is now available on GitHub in branch feature/android-handles (https://github.com/SFML/SFML/tree/feature/android-handles). Keep in mind that this is still unfinished, so might be buggy, and the interface is subject to change. The Android example is updated and triggers vibration, but that code isn't finished yet. Let me know in case there are any issues.
Title: Re: Android and iOS ports available for testing
Post by: Tank on October 19, 2015, 10:00:34 am
xGEKKOx: Your help is greatly appreciated. :)
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on October 19, 2015, 02:08:16 pm
My kind of coding is C++ mixed with OBJC and my friend BJ said that SFML is C++ but need some support on Apple side.
SFML works for iOS fluidly, there's no need for any apple support and you can mix your SFML with Obj-C without a problem.
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 20, 2015, 08:54:03 am
@BlueCobold what is the "true" status of SFML on iOS right now?

Does most of the SFML commandset work or are there problems?

Does it work on iOS9?

I would really love to get onboard SFML as I like how it works, but I need stable iOS functionality
Title: Re: Android and iOS ports available for testing
Post by: Laurent on October 20, 2015, 08:56:54 am
The iOS port is fully functional, everything is implemented. But it lacks testing and feedback, so you can expect more or less serious bugs. I have no idea if it works with iOS9, you should just try and tell us ;)
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 20, 2015, 08:58:40 am
so no one has been using iOS SFML since it was first made available?

its a real pity since iOS is one of the major platforms.

How about the Android port? Has it been tested and is in a stable status?
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on October 20, 2015, 09:00:19 am
I am using SFML on iOS for Rickety Racquet and can't complain so far. I currently do not have any issues, no matter if using iOS 7, 8 or 9. I'm still thinking to make a PR to be able to handle applicationWillResignActive and applicationDidEnterBackground on the user-side of the application, as it often requires the app to persist some kind of state.


Android looks pretty stable too, currently preparing to build/port it to Android.
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 20, 2015, 09:10:36 am
@BlueCobold much thanks for the good news

I think that SFML iOS should be publicized more. More people will get onboard SFML if they knew that the iOS port was usable to make games
Title: Re: Android and iOS ports available for testing
Post by: Gambit on October 20, 2015, 10:22:19 am
I know it has been explained time and time again (Even at my request), but if there was step by step instructions on how to configure iOS/Android projects, I would be more than happy to provide testing and feedback. I'm stupid with iOS/Android setup because its not as straight forward for me as normal CMake -> VSProject -> Compile/run.
Title: Re: Android and iOS ports available for testing
Post by: Laurent on October 20, 2015, 10:25:43 am
Quote
if there was step by step instructions on how to configure iOS/Android projects
What's the problem with the instructions at http://en.sfml-dev.org/forums/index.php?topic=13716.msg96044#msg96044 ?
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 20, 2015, 11:19:02 am
I'm stupid with iOS/Android setup because its not as straight forward for me as normal CMake -> VSProject -> Compile/run.
Give it some time, that might be the ultimate goal, considering how (at least) Visual Studio 2015 integrates mobile platforms now. :)
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 20, 2015, 11:48:49 am
as Gambit said, it would help people who just came across SFML if there were some kind of downloads or instructions on the main page, like there is for Windows
Title: Re: Android and iOS ports available for testing
Post by: Laurent on October 20, 2015, 11:55:47 am
Yes, I guess it would be a good idea to check whether the mobile ports can be officially released, and if not, list all the blocking tasks on the tracker -- and find someone to work on them (especially for iOS) :P
Title: Re: Android and iOS ports available for testing
Post by: bjadams on October 20, 2015, 12:52:35 pm
We must organise a SEARCH PARTY to find a knowledgeable ios developer to maintain the ios version
Title: Re: Android and iOS ports available for testing
Post by: Gambit on October 20, 2015, 03:07:33 pm
Quote
if there was step by step instructions on how to configure iOS/Android projects
What's the problem with the instructions at http://en.sfml-dev.org/forums/index.php?topic=13716.msg96044#msg96044 ?

Nothing I guess. I mean if they describe a process of going from the SFML source to an iOS/Android app then they are fine. However, I'm a Windows/GUI peasant :( I dont have make installed so I cannot run the make command in the Android instructions. I understand that the mobile ports are still in development and experiemental but I dont believe I'm too far from the truth in saying that a sizable portion of SFML users are Windows/GUI users like myself so instructions for Windows and the CMake GUI (Maybe with VS as well :o?) would be incredibly handy.

On the other hand I probably just sound incredibly lazy and stupid for asking for 1:1 steps.
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on October 20, 2015, 04:31:25 pm
The instructions for Android are pretty straight forward. You should really install MinGW though. CMake GUI is no magic, there's just 2 buttons and 2 textfields. The tutorials show it pretty good. iOS is not much different. Run CMake(-GUI), build+install everything with Xcode, create your app and import the frameworks to it.
Title: Re: Android and iOS ports available for testing
Post by: Mario on October 21, 2015, 11:20:03 am
Decoupled the retrieval of the activity handle from sf::Window::getSystemHandle() to a more generic sf::getSystemHandle() which will return the process handle on other platforms (even though it's trivial).

Testing branch is available here: https://github.com/SFML/SFML/tree/feature/system-handle
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on October 21, 2015, 01:07:10 pm
Tested and accepted :D
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 18, 2015, 05:54:20 pm
To get some movement again into this, the branch mentioned in my previous post has been updated with an "Android only" implementation and there's now a pull request (https://github.com/SFML/SFML/pull/1005) for discussion/comments.
Title: Re: Android and iOS ports available for testing
Post by: bjadams on November 26, 2015, 10:24:01 pm
will there ever be an official android & ios working version or will it stay as wip forever?
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 26, 2015, 10:43:28 pm
There are tutorials how to build them and there are sample applications. Except an announcement, it can't really get much more official than that.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on November 30, 2015, 02:18:20 pm
Hello! Quick question - is there any SF-way to get dir structure inside of apk assets? :)
If not - do You know any? I tried dirent.h, but it's not working inside of apk.
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 30, 2015, 02:37:10 pm
At least not yet. You'll have to use the Asset Manager (http://developer.android.com/reference/android/content/res/AssetManager.html). However I don't have any snippet ready and I'm not sure whether there's NDK level access or whether you'd have to use the JNI to call Java stuff.
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 30, 2015, 02:51:20 pm
Afaik there's no "native" way of getting the apk structure. The NDK doesn't offer any class or method for that. You could use a zip-lib (also provided by the NDK) to explore the archieve. Or use a Java-call.
The Asset-Manager and Asset-Dir classes in the NDK only provide access to a file you already know the path of.
I just did exactly that recently (unpack a multi-layer deep asset-folder from the APK), so I'm pretty sure that's the only way (Java or zip-lib). It's easy to find a native snippet of using the Asset Manager to unpack a known directory or file though. There's various samples.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on November 30, 2015, 07:43:35 pm
Thank You both for Your answers :) I was looking at AssetManager examples before, but does even SFML give access to the required handles(JNIEnv* env, jobject clazz --- if that's even required or I did not understand the examples)?
Title: Re: Android and iOS ports available for testing
Post by: Mario on November 30, 2015, 07:55:20 pm
Check the test branch I've mentioned on last page. It has a new function that will expose the native handle. Check the included Android example for JNI interaction (that function is still WIP though).
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on November 30, 2015, 08:35:56 pm
Jup, I'm using the branch Mario mentioned to grab the AssetManager and extract my files.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on December 04, 2015, 05:27:48 pm
Another thing - sf::Vertex seems to be not rendering on Android. Is that a known bug?
Title: Re: Android and iOS ports available for testing
Post by: BlueCobold on December 04, 2015, 05:30:56 pm
Does this work on other platforms? Because I'd say a Vertex itself isn't actually drawable.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on December 04, 2015, 05:39:56 pm
Sure,

Quote
window.draw(rectangle, 4, sf::Quads);

this works on windows but does not on android.
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 04, 2015, 06:04:43 pm
Android uses OpenGL ES and OpenGL ES doesn't understand quads (which will silently fail at the moment). As a workaround, use some other primitive type.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on December 05, 2015, 01:04:18 pm
Thanks, that solved it :) Getting string from resources is also not possible directly through SFML right now?
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 05, 2015, 01:12:31 pm
You should be able to use SFML's InputStream for that, which I think is wrapped to the asset manager.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on December 05, 2015, 10:27:25 pm
Well, no, I think You're mistaking assets with resources now :) I'm not too familiar with whole android apk structure, but as far as I understood, strings get compiled with other resources description to resources.arsc and when You're creating a "standard" android apk You simply use @string/app_name to get app_name string, depending on user's language. It could be a neat feature for SFML(if that's even possible through native functions).
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 05, 2015, 10:58:05 pm
Ah ok, I thought you'd like to read strings from a text file. Reading string resources isn't exposed and you'd have to write the code for that yourself.
Title: Re: Android and iOS ports available for testing
Post by: Kori on December 27, 2015, 12:07:00 am
img.saveToFile("file.png");

not working for me. In LogCat is wrote "failed to save image". I am testing it on android.
If someone have time, pleas check it, because i don't know that this is my mistake or sfml bug.
Title: Re: Android and iOS ports available for testing
Post by: Zax37 on December 29, 2015, 05:03:01 pm
Maybe You don't have permissions to write to that file? Try that:

<manifest ...>
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    ...
</manifest>
Title: Re: Android and iOS ports available for testing
Post by: Mario on December 29, 2015, 06:18:31 pm
While I don't remember testing it so far, these functions should – in theory – work out of the box, given you're using the correct path (to be determined using the native context). This can be tricky and suggestions to improve this on SFML side are welcome. :)
Title: Re: Android and iOS ports available for testing
Post by: CJ_COIMBRA on December 29, 2015, 09:09:28 pm
Wow, great to see SFML on iOS. So far I only tested/played around on simulator, but if you guys need to test something on device count on me.
Title: Re: Android and iOS ports available for testing
Post by: CJ_COIMBRA on January 08, 2016, 08:58:07 pm
Is there a way to get applicationDidEnterBackground notification from iOS?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on January 08, 2016, 09:14:35 pm
No.

Don't hesitate to have a look at the source code ;)

https://github.com/SFML/SFML/blob/master/src/SFML/Window/iOS/SFAppDelegate.mm#L123
Title: Re: Android and iOS ports available for testing
Post by: CJ_COIMBRA on January 09, 2016, 06:07:07 am
Oh well, I could put a notification on didFinishLaunchingWithOptions from SFAppDelegate just like the one for orientation changes. I get the notifications now but I don't think it will help me back in my game as I was thinking.
Title: Re: Android and iOS ports available for testing
Post by: CJ_COIMBRA on January 12, 2016, 04:51:35 pm
Hello again,

I was wondering if someone can help me with this problem. After successfully building the libs my app will run on iPhone 4s and 5 simulators but fails on simulators 5s and up. I get this kind of warning for every module:

Quote
ld: warning: ignoring file /Users/christian/Desktop/SFMLtest/SFMLtarget/libsfml-network-s.a, file was built for archive which is not the architecture being linked (x86_64): /Users/christian/Desktop/SFMLtest/SFMLtarget/libsfml-network-s.a

And then tons of errors of course because of undefined stuff. Probably related to "architectures/valid architectures" but I don't know much about it. Tried a few changes but the problem remained. Any suggestions?
Title: Re: Android and iOS ports available for testing
Post by: Laurent on January 12, 2016, 08:27:25 pm
You probably need to build for 64 bits. But don't ask me how to do that ;D
Title: Re: Android and iOS ports available for testing
Post by: CJ_COIMBRA on January 12, 2016, 10:55:01 pm
Yeah, I did a lot of combinations until one of them worked out. Curiously it is was not the 64 bit one but this:
32 bit Intel (i386) $(ARCHS_STANDARD_32_BIT)
Title: Re: Android and iOS ports available for testing
Post by: imnaero on February 07, 2016, 02:54:07 am
Hello!

I've been trying all day to compile SFML for android and i have been following this guide:
https://github.com/SFML/SFML/wiki/Tutorial:-Building-SFML-for-Android

So far I've made it to actually building the android example by calling 'ndk-build'.
However when I do, i get a load of errors. It seems to start out well and then fails when it reaches a shared
library in main.cpp. I can't make any sense of what it's looking for that isn't there and when i should have created that object.

Here are my errors, can any of you brilliant people infer from this what i might have done wrong?

EDIT: I have circumvented this issue by changing this line in my Application.mk:
APP_STL := gnustl_shared (instead of c++shared)

C:\Androidstuff\SFML\examples\android>ndk-build -B
[armeabi-v7a] Prebuilt       : libsfml-activity.so <= <NDK>/sources/sfml/lib/arm
eabi-v7a/
[armeabi-v7a] Install        : libsfml-activity.so => libs/armeabi-v7a/libsfml-a
ctivity.so
[armeabi-v7a] Compile++ thumb: sfml-example <= main.cpp
[armeabi-v7a] Prebuilt       : libsfml-graphics.so <= <NDK>/sources/sfml/lib/arm
eabi-v7a/
[armeabi-v7a] Prebuilt       : libsfml-audio.so <= <NDK>/sources/sfml/lib/armeab
i-v7a/
[armeabi-v7a] Prebuilt       : libsfml-network.so <= <NDK>/sources/sfml/lib/arme
abi-v7a/
[armeabi-v7a] Prebuilt       : libc++_shared.so <= <NDK>/sources/cxx-stl/llvm-li
bc++/libs/armeabi-v7a/thumb/
[armeabi-v7a] Prebuilt       : libsfml-window.so <= <NDK>/sources/sfml/lib/armea
bi-v7a/
[armeabi-v7a] Prebuilt       : libsfml-system.so <= <NDK>/sources/sfml/lib/armea
bi-v7a/
[armeabi-v7a] SharedLibrary  : libsfml-example.so
jni/main.cpp:10: error: undefined reference to 'sf::String::String(char const*,
std::__1::locale const&)'
jni/main.cpp:13: error: undefined reference to 'sf::Texture::loadFromFile(std::_
_1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >
const&, sf::Rect<int> const&)'
jni/main.cpp:21: error: undefined reference to 'sf::Music::openFromFile(std::__1
::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > co
nst&)'
C:/Androidstuff/android-ndk-r10e/sources/sfml/lib/armeabi-v7a/libsfml-main.a(Mai
nAndroid.o):MainAndroid.cpp:function ANativeActivity_onCreate: error: undefined
reference to 'std::basic_ios<char, std::char_traits<char> >::rdbuf(std::basic_st
reambuf<char, std::char_traits<char> >*)'
C:/Androidstuff/android-ndk-r10e/sources/sfml/lib/armeabi-v7a/libsfml-main.a(Mai
nAndroid.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefin
ed reference to 'std::locale::~locale()'
C:/Androidstuff/android-ndk-r10e/sources/sfml/lib/armeabi-v7a/libsfml-main.a(Mai
nAndroid.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefin
ed reference to 'std::string::_Rep::_M_destroy(std::allocator<char> const&)'
C:/Androidstuff/android-ndk-r10e/sources/sfml/lib/armeabi-v7a/libsfml-main.a(Mai
nAndroid.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefin
ed reference to 'std::string::_Rep::_S_empty_rep_storage'
C:/Androidstuff/android-ndk-r10e/sources/sfml/lib/armeabi-v7a/libsfml-main.a(Mai
nAndroid.o):MainAndroid.cpp:function onDestroy(ANativeActivity*): error: undefin
ed reference to 'vtable for std::basic_streambuf<char, std::char_traits<char> >'

C:/Androidstuff/android-ndk-r10e/toolchains/arm-linux-androideabi-4.8/prebuilt/w
indows/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideab
i/bin/ld.exe: the vtable symbol may be undefined because the class is missing it
s key function
collect2.exe: error: ld returned 1 exit status
make.exe: *** [obj/local/armeabi-v7a/libsfml-example.so] Error 1

C:\Androidstuff\SFML\examples\android>
Title: Re: Android and iOS ports available for testing
Post by: Mario on February 09, 2016, 09:08:15 am
Haven't tried latest NDK so far, maybe they've changed something. From first guess looks some issue with linking order.
Title: Re: Android and iOS ports available for testing
Post by: johnyrex on July 21, 2017, 07:44:17 am
Hi

The iOS/Android ports are finally ready for beta-testing. This happens one month after the expected date, sorry for the delay (everyone is very busy -- more than usual). Until Jonathan pushes the code to the public repository, here is what you need to know if you want to play with them.

Where?

The ports will be available in the ios_and_android branch of the repository. This way it won't bother people who are not interested, and the amount of testers (and reports) is kept under control.

How to compile the iOS port?

To compile the iOS port, you must use the Xcode generator of CMake, and define the "IOS" boolean variable (set to TRUE) before configuring for the first time. The generated projects can then be compiled for x86 (simulator) or armv6/v7 (device) by selecting the target in Xcode; no need to generate multiple builds for that. SFML is built as static libraries on iOS (this is the only option for this OS).

To use SFML in your iOS app project, do as usual: add the include path to your project settings, and drag'n'drop the libraries into your project. Since SFML is linked statically, you'll have to link all its non-default dependencies as well (extlibs/libs-ios).
Note that you'll need a registered Apple developer account in order to copy and run your app on a device; otherwise the simulator will be your only choice.

How to compile the Android port?
How to compile the OpenGL ES port for Linux?
Things to know for Android

Jonathan will explain that as soon as he is available ;)

New API

Only a few things have been added to the public API:
  • The sf::Keyboard::setVirtualKeyboardVisible function
  • The Touch API:
    • A sf::Touch class (similar to sf::Mouse)
    • sf::TouchBegan / sf::TouchMoved / sf::TouchEnded events (similar to mouse events)

General things to know

The sensors (accelerometer, gyroscope, compass, ...) are currently using the Joystick API (see the sources for more detail about the mapping). We'll soon add a sf::Sensor API that better matches the requirements.

The foreground / background events are mapped to the GainedFocus and LostFocus events.

Orientation changes are mapped to the Resize event.

sf::Shader is not available, because the implementation is based on OpenGL ES 1. Shaders are only available in OpenGL ES 2, which would require a major rewriting of the graphics part. So that won't be done in a near future.

Things to know for iOS

On iOS, the working directory is automatically set to the resources directory.

There's no audio module on iOS, I'm still waiting for libsndfile to add a license exception for iOS so that I can use it statically without breaking the terms of the license. The author said it was one of its priorities, but it was months ago and I've got no news...

The implementation should be compatible with iOS 4.0 and more.

The size of the window is ignored, the screen size is always used.

Examples are not available. It seems that CMake is not ready for that, it still requires too many hacks, and even with them, it was still pretty bad.

The ugly hack: you need to include <SFML/Main.hpp> in the file where your main function is defined. This is because SFML has to hijack it, and rename your own main to call it later.

There's no specific support for high-resolution (retina) screens, they currently produce the same output as low-res screens (this will be done later).

Important

Until everything is merged into master, please use the forum for your feedback. You can post here or open new threads. There are still many things to do, I don't want to pollute the task tracker ;)

Thanks @Laurent
Title: Re: Android and iOS ports available for testing
Post by: eigen on May 14, 2018, 10:15:54 pm
Hey guys.

So, I was testing out the iOS port last night for my game City Clickers and it seems to work sufficiently enough. Adding touch in addition to mouse controls was really straightforward. Have some weird flickering at launch (the whole screen is magenta for a moment), hopefully something I can track down. I'm not sure about actually targeting iOS, just experimenting for now but it seems promising.

Two quick questions:
1) Are render textures supposed to work on iOS?
2) As I understand, shaders are not supported due to older OpenGL ES and upgrading is quite a bit of work. How much work you reckon? What are the roadblocks? Given some good pointers, could I (with no real graphics programming experience) make something work?

It's pretty much the only thing I'm really missing atm. I have a post-processing shader to get the look I want, sort of complicated to achieve without it.

I guess I can work around something somehow but that would be an awesome addition/upgrade to the library.

The exciting moment I first got everything playable:
(https://i.imgur.com/FeUP883.jpg)
Title: Re: Android and iOS ports available for testing
Post by: eXpl0it3r on May 14, 2018, 10:40:21 pm
Really cool seeing the porting to be quite okay. :)

I'd say it's quite a bit of work and you'll have to adjust for some changes. Doing it without thinking about backwards compatibility probably makes things a bit easier.
Personally I haven't dug into the depth of SFML's rendering, but you'd have to most likely change quite a bit regarding context management, then you'd have to change all the rendering for modern OpenGL and finally, you'll have to ditch the current shader implementation and adjust it for modern OpenGL.

The final part is, what we've been discussion not very actively in this thread (https://en.sfml-dev.org/forums/index.php?topic=20767.0) and it's the first stepping stone towards modern OpenGL.
Title: Re: Android and iOS ports available for testing
Post by: Mario on July 28, 2018, 06:40:57 pm
Just to mention it here for everyone subbed to the thread: SFML's current master branch on GitHub should once again build and run Android properly for everyone, even if you're using the audio module and/or use the shared C++ runtime. Apps will still fail to regain a working context once you switch out of them, though.