-
Notifications
You must be signed in to change notification settings - Fork 3
Home
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.
Contents:
Before reading the other pages (such as the roadmap), it would be great if you could read this page entirely to get a bit of context.
Mobile device support, such as for iOS and Android, is the most requested feature. Unlike desktop computer applications, mobile devices don't run in a windowed environment. Some peripheral devices are either missing or replaced by others more suitable for mobiles; the mouse is either missing or replaced by finger motion sensor and the keyboard is either virtual or physically different than keyboards made for desktop computers. These differences involve redesigning the entire window module. Mobile devices support only a subset of the OpenGL API called OpenGL ES as they don't have powerful graphics cards.
These are the issues SFML3 will have to face and that's how this project hopes to help. This project doesn't pretend to solve all these issues but will probably give a first functional snapshot of what the future SFML3 could be.
I'll make the changes in the following steps:
- Support for OpenGL ES 1.x (easily portable)
- Support for Android and iOS (without breaking the API)
- Later on Support OpenGL (ES) version
- Attempt to provide the future SFML3 design, one which takes mobile environments into account.
- Apply the new design to Android/iOS.
More on this later, in the Strategy section.
My biggest motivations is having my Python bindings working on iOS and Android.
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. I'm open to everyone suggestion, nobody will be left unanswered and, on the contrary, I'll attempt to summarize all solutions proposed with their pros and cons because at the end this is more a study of "how to integrate dev mobile apps with a future SFML version" rather than a straight forward upgrade.
I also have personal motivations: mastering OpenGL and being part of GSOC as student.
So far, only OpenGL ES 1.x is supported but the final goal is:
OpenGL supported versions: min: 2.0 max: 4 default: 3.2 (deprecated methods removed)
OpenGL ES supported versions: min: 1.1 max: 3.0 default: 2.0
OpenGL ES 1.1 is close to the current OpenGL versions supported by SFML (2.0 -> 3.1) which makes the task easier. This allows me to quickly have a first SFML version compatible on embedded systems running Linux with X11 such the Raspberry Pi. Unfortunatly, OpenGL ES 1.1 doesn't support shaders and so won't run the shader example (you'll see a a text that says "shaders are not supported on your system" as sf::Shader:isAvailable returns False).
Now we have an OpenGL ES version supported, we can port to these OSes but the issues quoted in the Introduction section remain: SFML is not designed for these environments. How would you handle the finger motion sensor without breaking the API ? Hopefully, this is close to how a mouse works so as a workaround it will regards these events as being mouse events. Creating multiple windows won't work and the requested video mode will be ignored, you'll have to check the actual one, but all these things are explained in the specific OSes sections...
Newest OpenGL versions don't keep backwards compatibility and is based on shaders more and more. Everything becomes a shader (matrices, movements, etc.). It also introduces a new kind of shader: geometry shaders. I'm currently studying this part and so far I can't say much about it. It shall support OpenGL ES 2.x and 3.x, and then OpenGL 3.2 and 4.x at the end. Once this is done and stable we can jump to the next task: "How to upgrade SFML to support iOS and Android environments?"
This is a huge task, not in term of complexity but in the terms of making good choices. There's not one straight forward way to upgrade the SFML design. This will need to be amply discussed with the communauty and Laurent in order to make the best choices. I already explained my philosophy on the subject.
Once the new design is good it will be an easy task to upgrade the existing port to the new design. Also why not support other mobile platform such Symbian or Windows Phone (if OpenGL is available) etc while we're at it.
I believe in a design generic enough to have one code compiling for all targeted platforms, with minimum care about their differences; a desktop computer is not a laptop which is neither a tablet nor a smartphone, however, one piece of code should adapt its behaviour to take advantages of the underlying device. For example: the pong example could use the orientation sensor of a smartphone to move the paddle while a desktop computer would use the mouse, and this would happen with maximum transparency at the code level. This task doesn't require the use of a condition to know which platform it's running on and so, what code to use.
Simple doesn't exclude complete as long as the new features allow great and big things. That must answer to the following question: where do we stop completeness? E.g: Implementing sf::Camera to use the webcams available is first closely related to the SFML theme 'multimedia' and provides a high degree of abstraction, and cross platform support. Therefore, sf::Camera is a good candidate for SFML3. As for being simple, I think the names given to functions and classes should match reality.
These are personal opinions which shouldn't matter because (1) I don't own the project, (2) maybe I don't have enough experience and (3) I haven't discussed them with the community yet :) But I do know SFML and have been using it for years. Being a first customer, I know how I'd like it to be improved and that's why I take this liberty.
What I like is how simple learning and using SFML is. Why is it easy ? Because the abstraction is high, cross-platform and well designed. With only a few classes it allows a complete set of basic drawing operations to be performed and if people want more they just have to build on top of that. Wrapping Open GL in C++ using the POO paradigm was a challenge Laurent did perfectly. You can either entirely rely on SFML or go deeper and deal with OpenGL commands with minimal drawback (usage of reset/pop/restore_gl_states functions). SFML is functional, comes almost without any bugs because it focuses on the most important tasks and leaves the rest to external libraries. This is a good thing because a library with hundred of features people don't need kills the library.
- Source files renamed (lowercase) (commit: e116ca7ff6c3e8eb7af7f4bc8b8af8b17c06e731)
- Add a main header: sfml.hpp (commit: e1308f34ec7a633d9c3f987d74d5bf64715991a4)
- Coding conventions slightly modified (//// trailing up to 80, headers)
- Refactor examples directories to share media files
- A single library is built by default (libsfml.so or sfml.dll)
- Unit tests
- Eclipse plugin for Android app using SFML
- Java binding for SFML (on Android)
- Objective-C binding for SFML (on iOS)
- Rename BUILD_SHARED_LIBS to SFML_LIBRARY_TYPE
- Rename CMAKE_BUILD_TYPE to SFML_BUILD_TYPE
- Support value "Both" for multiple build in one
make - Add option to build SFML modules into a single library: SFML_BUILD_MODULES
- Less used options marked as advanced
- Handle matrix at hand
- Support geometry shaders
- Shaders supporting both ARB extension and the official API.
- A generic and extensible callback mechanism (signals & slots)
- Output level (debug, info, warning)
- Maybe a more complete mathematical background ?
- Redesign as there's no windows environment on mobiles OS
- Support physical and virtual keyboard
- Support font edition
- Support later OpenGL versions
- New shapes ?
No plans for this module as I'm not an expert in sounds/musics.
- Support IPv6
- New protocols: HTTPS, SSL, ... ?