Android port: questions / remarks

[piec]

Hi,

First of all thanks for sfml it's a nice & clean library, I like to use it on desktop OS. I want to start a project on mobile (at least android / ios) so I am considering sfml. I have a few questions and remarks:
(I'm using yesterday's head version)

• the build process is simple and fast, good job on that compared to other libraries. Just one thing to report: I've tried the standalone build mode but the cmake script was always complaining about the api level - I tried to make several standalone toolchains with different api levels. Anyway this isn't too much important for me
• the android sample sets gles version to 1.1. I think sfml only supports gles 1.1 and not 2.0, correct?
• When running the android sample on my device the application should pause, stop rendering etc. But apparently this is not the case, the main loop appears to be running and floods android's log with "I/sfml-error(20853): Failed to activate the window's context" messages. I don't know if it's a problem in the sfml android port or in the example but it doesn't give confidence in sfml on android.
  Apparently sfml handles the onPause event and forwards it to the application as a MouseLeft event, onResume is MouseEntered, ... 
  Other activity events seem to be ignored (see on* functions), the android application lifecycle doesn't seem to be well supported to me, correct?
• the build process produces several several dynamic libraries (.so) libopenal.so libsfml-activity.so libsfml-audio.so libsfml-example.so libsfml-graphics.so libsfml-network.so libsfml-system.so libsfml-window.so it's nice when developing but when releasing I'd rather have sfml as a static library to make things smaller and also load faster
• in their native activity sample google use native_app_glue which has a nice architecture, using it prevents you from blocking the activity's main thread: the activity threads posts events to the "game" thread using pipes, and the "game" thread polls for new messages  in its main loop. The sfml android port seems to be inspired from native_app_glue but doesn't seem to use that principle, why?

So I'm not sure I'm going to use sfml on mobile, is it really well fitted for it? lack of integration in mobile systems (I haven't looked at ios)?
Thanks for your work!
Cheers

[Mario]

• the build process is simple and fast, good job on that compared to other libraries. Just one thing to report: I've tried the standalone build mode but the cmake script was always complaining about the api level - I tried to make several standalone toolchains with different api levels. Anyway this isn't too much important for me

Which value did you set? As far as I remember, the minimum supported API level for SFML is 9 or 10.

• the android sample sets gles version to 1.1. I think sfml only supports gles 1.1 and not 2.0, correct?

Yes, so far it creates a 1.1 context only. 2.0 needs a rewrite of the graphics library (which is also true for higher OpenGL versions for desktop builds, which is the reason this didn't happen so far).

• When running the android sample on my device the application should pause, stop rendering etc. But apparently this is not the case, the main loop appears to be running and floods android's log with "I/sfml-error(20853): Failed to activate the window's context" messages. I don't know if it's a problem in the sfml android port or in the example but it doesn't give confidence in sfml on android.
  Apparently sfml handles the onPause event and forwards it to the application as a MouseLeft event, onResume is MouseEntered, ... 
  Other activity events seem to be ignored (see on* functions), the android application lifecycle doesn't seem to be well supported to me, correct?

Yes, I'm not happy with that either, but it's how it's set up right now. The window events (focus and mouse) for mobile are essentially swapped and not very clear.

• the build process produces several several dynamic libraries (.so) libopenal.so libsfml-activity.so libsfml-audio.so libsfml-example.so libsfml-graphics.so libsfml-network.so libsfml-system.so libsfml-window.so it's nice when developing but when releasing I'd rather have sfml as a static library to make things smaller and also load faster

Again (same for last point), I'd really love to change this, but lack of time and I'll have to learn how that part of the code works first as well. I'd definitely love to have a single so file per app.

• So I'm not sure I'm going to use sfml on mobile, is it really well fitted for it? lack of integration in mobile systems (I haven't looked at ios)?

It's labelled as experimental and that's it, really. You definitely can create and release games with it, there have been a few on Google Play already, but at the same time, yes, this is far from being finished.

Overall, the big idea here is to allow the user to use one single code base, without having to worry about any platform specific entry points or setup functions. You write your code into your main() entry point and it will be used, no matter whether you compile for Linux, Windows, MacOS X, Android or any other platform. SFML definitely hasn't reached that point for the mobile ports (at least it's not as streamlined/easy to use as I'd like it to be (and others probably as well)).

[piec]

Thanks for your quick and thorough answer

Which value did you set? As far as I remember, the minimum supported API level for SFML is 9 or 10.

At first I tried 21, then 9. I didn’t dig more

Again (same for last point), I'd really love to change this, but lack of time and I'll have to learn how that part of the code works first as well. I'd definitely love to have a single so file per app.

Yep I think it’s not too complicated but it still takes time…

It's labelled as experimental and that's it, really. You definitely can create and release games with it, there have been a few on Google Play already, but at the same time, yes, this is far from being finished.

Overall, the big idea here is to allow the user to use one single code base, without having to worry about any platform specific entry points or setup functions. You write your code into your main() entry point and it will be used, no matter whether you compile for Linux, Windows, MacOS X, Android or any other platform. SFML definitely hasn't reached that point for the mobile ports (at least it's not as streamlined/easy to use as I'd like it to be (and others probably as well)).

Yes I understand the intention, and there’s still stuff to do.
Thanks you for your work

[R23MJ]

I have created an iOS game with it, and SFML, despite it's hacking method, works amazingly. I had more trouble working with Apple then I did SFML. My game uses a ton of textures and sprites, yet still my phone (iOS 9, 5c) stays solid at 60FPS with only 18mb of RAM used.

As far as android goes, I haven't tackled that yet, I plan on doing so as soon as I can. If you beat me to it you should explain how everything went. Problems linking/compiling, or problems working with Google, just the process as a whole.