Android Support and OpenGL ES 2.0

[Cornstalks]

I want to help with Android support. I've read Sonkun's post and didn't want to derail that thread further, so I'm starting this thread.

Questions for Laurent:

• What can I do to help get Android supported?
• OpenGL ES 2.0 would be awesome. At what point do you think SFML would use OpenGL ES 2.0? I assume after SFML 2.2.
• Is there anything I can do that would help get OpenGL ES 2.0 support into SFML (even if it's quite awhile down the road)?

Questions for Sonkun:

• Are you using a NativeActivity? Or are you using JNI?
• Is there anything I can do that would help you in your work as well?

[Laurent]

What can I do to help get Android supported?

Write the Android port

OpenGL ES 2.0 would be awesome

Why?

At what point do you think SFML would use OpenGL ES 2.0? I assume after SFML 2.2.

Since both iOS and Android wupport OpenGL ES 1.1, I'll go this way first. Supporting OpenGL ES 2.0 requires a lot more work, for very little gain. And if I can't do it without breaking the public API, it won't happen before SFML 3.0.

Is there anything I can do that would help get OpenGL ES 2.0 support into SFML (even if it's quite awhile down the road)?

Don't bother with this, it's really too prematurate.

[Cornstalks]

What can I do to help get Android supported?

Write the Android port

Sweet, looks like I've got a new project.

OpenGL ES 2.0 would be awesome

Why?

Because I much prefer the programmable pipeline over the fixed function pipeline. And unless I'm misreading something, OpenGL ES 1.1 doesn't support shaders, which makes me wonder what the Shader class will be doing...

Plus OpenGL ES 2.0 is one step closer to ES 3.0

But I don't expect 2.0 support in SFML anytime soon.

[Laurent]

Because I much prefer the programmable pipeline over the fixed function pipeline

But here we talk about SFML and its graphics module, not about OpenGL. Porting SFML to OpenGL ES would break a lot of internal code, but change very little things for the end user.

And unless I'm misreading something, OpenGL ES 1.1 doesn't support shaders, which makes me wonder what the Shader class will be doing...

Hum... never thought about it. If there's no way to have shaders with OpenGL ES 1.1, the first version of the iOS port will not have sf::Shader.

[Grimshaw]

And later when you go to OpenGL ES 2.0, you need to reintroduce sf::Shader, and only shaders are allowed.. If you ever aim to support both versions it will be a little weird.

[Cornstalks]

And unless I'm misreading something, OpenGL ES 1.1 doesn't support shaders, which makes me wonder what the Shader class will be doing...

Hum... never thought about it. If there's no way to have shaders with OpenGL ES 1.1, the first version of the iOS port will not have sf::Shader.

Doesn't that break the public API though? In which case, we won't be waiting for SFML 3.0 to break the API if OpenGL ES 1.1 is targeted...

And later when you go to OpenGL ES 2.0, you need to reintroduce sf::Shader, and only shaders are allowed.. If you ever aim to support both versions it will be a little weird.

Agree

[Sonkun]

What can I do to help get Android supported?

Write the Android port

I don't get it, why should he write another Android port ?

I thought it was a community project and that anyone could help with. I provided OpenGL ES 1.1 support + an Android port, I was expecting you to consider a merge, not ignore me.

At what point do you think SFML would use OpenGL ES 2.0? I assume after SFML 2.2.

Since both iOS and Android wupport OpenGL ES 1.1, I'll go this way first. Supporting OpenGL ES 2.0 requires a lot more work, for very little gain. And if I can't do it without breaking the public API, it won't happen before SFML 3.0.

Is there anything I can do that would help get OpenGL ES 2.0 support into SFML (even if it's quite awhile down the road)?

Don't bother with this, it's really too prematurate.

As for priorities, I don't have the same point of view. OpenGL ES 1.x and OpenGL 2.0 are old versions (as if you were using SFML 1.6) and advanced learners and users would want to interpolate with recent OpenGL versions. SFML would end up being mainly used by novice programmers who barely know what a shader is.

But this is just my opinion: newer OpenGL (ES) support should be a priority.

Also, supporting newer OpenGL (ES) verions wouldn't break the API and doesn't prevent SFML from being ported to iOS and Android at the same time. These tasks could be parallelized and help from the community should pull SFML3 development forward.

Are you using a NativeActivity? Or are you using JNI?

NativeActivity is a C interface provided by Android to deal with Android activities.
JNI is a C interface to communicate with Java apps in C code.

So technically I use both but mainly the first, look at all Android C headers located in the NDK directory (platforms/andoird-9/arch-arm/usr/include/android).

Is there anything I can do that would help you in your work as well?

Well, I would actually appreciate your help. I need to rebase the project on the latest SFML commit, then write a page on how to compile and use. After, you could start porting the network module ? Not to waste your time, I'd prefer you to wait until these two tasks are done and I explain you how it works (Android native apps have a special workflow as they communicate with java apps).

What can I do to help get Android supported?

Write the Android port

Sweet, looks like I've got a new project.

Cool, so... every man for himself ?

[FRex]

Doesn't that break the public API though? In which case, we won't be waiting for SFML 3.0 to break the API if OpenGL ES 1.1 is targeted...

Not really, sf::Shader::isAvailable would just always return false and you'd get errors in standard err about not checking it before using sf::Shaders. The latter is actually in place already.

    // First make sure that we can use shaders
    if (!isAvailable())
    {
        err() << "Failed to create a shader: your system doesn't support shaders "
              << "(you should test Shader::isAvailable() before trying to use the Shader class)" << std::endl;
        return false;
    }

[Nexus]

I don't get it, why should he write another Android port ? [...]  I was expecting you to consider a merge, not ignore me.

Laurent didn't say "write another Android port from beginning", he only said "Write the Android port". I'm sure he didn't mean to ignore your work (also from his reaction to your announcement in the other thread), please don't intentionally misunderstand statements

Also, supporting newer OpenGL (ES) verions wouldn't break the API and doesn't prevent SFML from being ported to iOS and Android at the same time. These tasks could be parallelized and help from the community should pull SFML3 development forward.

Consider that SFML 3 is also the result of experiences with SFML 2. It's certainly a good idea to have OpenGL ES 2 in mind when designing the SFML 3 API, additionally there could be other insights how SFML 2 can be improved -- those show only after a certain time.

[Cornstalks]

Are you using a NativeActivity? Or are you using JNI?

NativeActivity is a C interface provided by Android to deal with Android activities.
JNI is a C interface to communicate with Java apps in C code.

I know, maybe I should've worded it better. Were you expecting programs using your port to be written in native code and use a NativeActivity, or in Java (and calling SFML through JNI)?

So you're targeting native code programs using a NativeActivity, if I read the right.

Is there anything I can do that would help you in your work as well?

Well, I would actually appreciate your help. I need to rebase the project on the latest SFML commit, then write a page on how to compile and use. After, you could start porting the network module ?

Sure, I can work there. I'll watch your github project and wait for a bit.

Not to waste your time, I'd prefer you to wait until these two tasks are done and I explain you how it works (Android native apps have a special workflow as they communicate with java apps).

I've used the NDK before and have written a small native app (using a NativeActivity), but sure, more info is always welcome. I'm not sure what your opinion is on this, but I don't think SFML for Android should worry about communicating with Java apps. SFML for Android should, in my opinion, focus solely on native code and native apps (using NativeActivity). Java based Android apps can use JSFML to make the JNI calls to the native backend. I'm not sure what your thoughts are on that though...

What can I do to help get Android supported?

Write the Android port

Sweet, looks like I've got a new project.

Cool, so... every man for himself ?

Easy there, tiger. I didn't necessarily mean I'm starting my own port. My "new project" could very well be "your project."

[Cornstalks]

Doesn't that break the public API though? In which case, we won't be waiting for SFML 3.0 to break the API if OpenGL ES 1.1 is targeted...

Not really, sf::Shader::isAvailable would just always return false and you'd get errors in standard err about not checking it before using sf::Shaders. The latter is actually in place already.

    // First make sure that we can use shaders
    if (!isAvailable())
    {
        err() << "Failed to create a shader: your system doesn't support shaders "
              << "(you should test Shader::isAvailable() before trying to use the Shader class)" << std::endl;
        return false;
    }

Ah, didn't see that. That should work, then.

[Sonkun]

I don't get it, why should he write another Android port ? [...]  I was expecting you to consider a merge, not ignore me.

Laurent didn't say "write another Android port from beginning", he only said "Write the Android port". I'm sure he didn't mean to ignore your work (also from his reaction to your announcement in the other thread), please don't intentionally misunderstand statements

Oh :/ Sorry for this misunderstanding >.< (and that wasn't intentional at all!).

Also, supporting newer OpenGL (ES) verions wouldn't break the API and doesn't prevent SFML from being ported to iOS and Android at the same time. These tasks could be parallelized and help from the community should pull SFML3 development forward.

Consider that SFML 3 is also the result of experiences with SFML 2. It's certainly a good idea to have OpenGL ES 2 in mind when designing the SFML 3 API, additionally there could be other insights how SFML 2 can be improved -- those show only after a certain time.

I don't forget that, that's why I mentioned the API compatibility in the other post. I also think that changes which would break the API should be kept for SFML 3.0. I just pointed out that supporting newer OpenGL versions wouldn't break the API.

Easy there, tiger. I didn't necessarily mean I'm starting my own port. My "new project" could very well be "your project."

Really sorry about that. I'm not a tiger but a nice guy who doesn't bite :p I'm not a English native speaker which may explain why I misunderstood.

Sure, I can work there. I'll watch your github project and wait for a bit.

Actually I just have to finish packaging for the Python bindings, then I'll MP you

I've used the NDK before and have written a small native app (using a NativeActivity), but sure, more info is always welcome. I'm not sure what your opinion is on this, but I don't think SFML for Android should worry about communicating with Java apps. SFML for Android should, in my opinion, focus solely on native code and native apps (using NativeActivity). Java based Android apps can use JSFML to make the JNI calls to the native backend. I'm not sure what your thoughts are on that though...

Of course, SFML for Android apps don't deal with JNI or Java and are just pure C++ app using only the SFML. But SFML may use JNI to forward call to the Jave default app which come with any native Android app. (more on this later^^)

[Sonkun]

Again, sorry for the misunderstanding. Maybe I overacted because I put a lot of effort into this and was expecting it to be , at least, partially used.^^

Easy there, tiger. I didn't necessarily mean I'm starting my own port. My "new project" could very well be "your project."

Actually, "my" project is everyone's project. As mentioned in the wiki main page:

The main goal of this project is to experiment with SFML integration on embedded systems such as mobile devices; mostly smart-phones and tablets. It's only intending to help the original project by providing a working extension to SFML. Its author, Laurent Gomila, could later integrate, piece by piece, the code he wants as he sees fit. It also allows external developers to contribute without polluting the main project.

This page, https://github.com/Sonkun/esfml/wiki, introduces the project.

[Laurent]

My apologies, my answer was really badly worded. It was just a generic answer, out of context. It's obvious that any effort on the Android port should be based on your project, given the amount of work that you've already provided.

I don't understand th need to support newer OpenGL ES versions, since it's just a hidden implementation detail. It won't change anything for users. The only thing that could be seen in the public API is the ability to create contexts of newer versions, when using SFML as a context creation library. But since there are already good libraries that support this feature (such as SDL), I don't think it's a priority for SFML.

Starting simple in order to release quickly, and improving the ports later, sounds like a good plan in my opinion.

[Cornstalks]

Sonkun, I'm looking at your code and I've got a few questions:

• Why did you change all the file/folder names (SFML -> sfml)? Actually, only some of them were changed. I'm worried that this change, and the fact that you had this massive commit might make Laurent cringe.
• What is your preferred way of me communicating with you? I'm used to mailing lists, and as SFML doesn't have one, I just use these forums. Do you have a preferred way of trying to discuss things (issues, goals, milestones, etc.)?

@Laurent: How do you plan on continuing to support 3rd party libraries? Just keep checking in binaries into the repo? Is there a particular reason for you committing 3rd party binaries into the repository as opposed to having the user build them him/herself (with the cmake scripts configuring them)? I'm guessing some of them might require a Unix-like system?

Also, how do you plan on handling licensing issues? I'm guessing you won't include OpenALsoft and libsndfile in Android/iOS builds (and instead just use native APIs)? Their LGPL licences aren't good. iOS can't do dynamic linking (thus requiring you to either open source your application or release your object files so users can relink it). Android can dynamically link, but there are some annoying hoops to jump through to comply with the LGPL.