Android Support and OpenGL ES 2.0

[Laurent]

@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?

I'll always include 3rd party libraries that can't be installed easily on the user's system. Which means that I'll provide all Windows dependencies, none of the Linux dependencies and some OS X dependencies.

Also, how do you plan on handling licensing issues?

The iOS SDK provides its own OpenAL static library (OpenAL is just a standard, like OpenGL). But I'll have to drop libsndfile, indeed. Don't know about Android.

[Grimshaw]

For android there is OpenAL Soft with a OpenSL ES 1.1 backend, I believe. That's pretty much the only way you ll find to make portable audio code

[Sonkun]

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.

More conventional. By doing so, it matches most of the existing libraries conventions (including the standard one and boost) and help SFML blend into :p

Even if the final goal is having the code added to the SFML code, I'll take the liberty of making any API changes; I regard this project as a dirty working directory and think this is an excellent opportunity to try out new stuff which might be liked or disliked.

Quote from the wiki main page.

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.)?

As you want I was going to rebase eSFML today actually. Do you use gmail ? There's a chatbox integrated (maybe not the most convenient but pick up one, I'll join ).

[Sonkun]

For android there is OpenAL Soft with a OpenSL ES 1.1 backend, I believe. That's pretty much the only way you ll find to make portable audio code

I do use OpenAL Soft

[Laurent]

More conventional. By doing so, it matches most of the existing libraries conventions (including the standard one and boost) and help SFML blend into :p

But doing this in SFML is an option, since it would break existing code on case-sensitive OSes.

[Grimshaw]

After having "converted" SFML into a fully portable library (ios/android) myself, i remember a few bumps on the road:

sf::String -> http://stackoverflow.com/questions/5630255/does-android-not-really-have-wchar-t
Audio -> needs a very specific backend to work
ios EAGL -> the default framebuffer is not the window, but a off-screen fbo now.
OpenGL ES -> went with a renderer base class and specializations for each OpenGL version
Texture::copyToImage() -> not possible anymore, breaks some code
sf::Shader -> would probably need refactoring (GLSL ES and GLSL are not equal)
Assets -> Stored in a zip file, instead of loose files in android. some formats will be compressed unless you do some tricks.

I don't remember the rest of issues right now, but i ll update later if i do. I think it will be a little harder than expected to have sfml fully working in android, in particular.