What can I do to help get Android supported?Write the Android port :P
OpenGL ES 2.0 would be awesomeWhy?
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.
Sweet, looks like I've got a new project.QuoteWhat can I do to help get Android supported?Write the Android port :P
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 (http://sfml-dev.org/documentation/2.0/classsf_1_1Shader.php) class will be doing...QuoteOpenGL ES 2.0 would be awesomeWhy?
Because I much prefer the programmable pipeline over the fixed function pipelineBut 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.
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...QuoteAnd 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.
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 :)
I don't get it, why should he write another Android port ?QuoteWhat can I do to help get Android supported?Write the Android port :P
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.QuoteAt 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.QuoteIs 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.
Are you using a NativeActivity? Or are you using JNI?NativeActivity is a C interface provided by Android to deal with Android activities.
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).
Cool, so... every man for himself ?Sweet, looks like I've got a new project.QuoteWhat can I do to help get Android supported?Write the Android port :P
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.
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.
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)?QuoteAre 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.
Sure, I can work there. I'll watch your github project and wait for a bit.QuoteIs 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).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...
Easy there, tiger. I didn't necessarily mean I'm starting my own port. My "new project" could very well be "your project."Cool, so... every man for himself ?Sweet, looks like I've got a new project.QuoteWhat can I do to help get Android supported?Write the Android port :P
Ah, didn't see that. That should work, then.QuoteDoesn'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;
}
Oh :/ Sorry for this misunderstanding >.< (and that wasn't intentional at all!).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 :)
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.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.
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^^)
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.
@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.
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 (https://github.com/Sonkun/esfml/commit/acb877fdb9deca737a882e4d6398732c0083779e) 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 :) ).
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 :)
More conventional. By doing so, it matches most of the existing libraries conventions (including the standard one and boost) and help SFML blend into :pBut doing this in SFML is an option, since it would break existing code on case-sensitive OSes.