A MORE RECENT VERSION IS AVAILABLE! HERE (http://en.sfml-dev.org/forums/index.php?topic=8247.0)
http://en.sfml-dev.org/forums/index.php?topic=8247.0
Hello everybody,
I wanted to let you know about my project, a python binding for sfml2. Also written with cython and it was forked from the official python binding written by Bastien Lénoard on the 20th November 2011 because I needed some features at once to write my current C++ projects in Python.
It has since then widely improved and I decided to share my work.
The release I'm about to introduce is based on a snapshot of sfml2 which was available on the 20th November 2011 that I used to call sfm1.9. I decided to stay and work with this version because maintaining a binding up-to-date with the very latest changes is time consuming (also because I have projects which depend on the binding and a change made in sfml2 involves a change in the binding which involves changes in all my projects).
This release version is v0.9 and I hope to provide for the next one (v1.0) a binding compatible with the release candidate; I've already started working on it.
Despite its dependency on the snapshot, it provides some features that may interest people.
What has changed since its fork ? (copy-paste from the documentation)
- network module implemented.
- sound module rewrited.
- some current limitation of the module have been fixed such the derivability of sf.Drawable.
- modules are implemented separately; you can import each module independently.
- support cython 0.16 (faster).
- many official examples are available and new examples have been added (such integrating with pyqt4).
- an extra-layer to the sfml has been added to avoid dealing with type and to provide more flexibility
- available trough depot in launchpad for ease of installation.
I suggest you to read the documentation to know more: http://openhelbreath.net/python-sfml2/0.9/doc/introduction.html
How to install ?
Just read the doc about compiling and if you are on ubuntu 12.04, packages are available trough a launchpad ppa. Type:
sudo apt-add-repository ppa:sonkun/sfml
sudo apt-get update
sudo apt-get install libsfml2-dev python-sfml2
Notes that the packages provide examples too, you may want to install sfml2-examples or/and python-sfml2-examples, then you just have to type:
sfml2-<examples name>
python-sfml2-<examples names>
For examples:
python-sfml2-pyqt4 # will run script pyqt4.py that use the binding.
sfml2-sound
pyton-sfml2-shader
If you are interested in following the version 1.0 development and having automatic updates, I'll set up another depot named sfml-development with sfml2-rc in and the binding as well.
Links:
Main website: http://openhelbreath.net/python-sfml2/
Documentation: http://openhelbreath.net/python-sfml2/0.9/doc/
Downloads: http://openhelbreath.net/python-sfml2/downloads/ or https://github.com/Sonkun/python-sfml2/downloads
Bug-tracker: http://openhelbreath.net/python-sfml2/flyspray/
Launchpad ppa: https://launchpad.net/~sonkun/+archive/sfml
What's the point of implementing something and then discouraging its use? Confusing people? :P
Maybe should I have said "preferred" instead" of "discouraged". I find more confusing not to have the sfml network module implemented than having it.
It allows you to port C++ projects more easily. With minor syntactic changes (all of which are documented), you can port your code without having to trod through the standard library's documentation. Later, you can replace bits and pieces you like with the standard Python's built-in equivalents.
I think it's important to stick to the native classes and functions, so that SFML code can interact nicely with the rest of the code, and not require type conversions and duplicated functions everywhere. A binding must look natural, as if it was directly developed in the target language.
That's exactly what my binding offer compared to the official's one, a more natural look and on many points:
1) Types
In Python, numeric types (integer, float, complex, long) are inferred. Users shouldn't care about the Vector's type or Rect's type.
In my binding, instead of writing:
sf.Vector2f()
sf.Vector2i()
sf.IntRect()
sf.FloatRect()
You write:
sf.Vector2()
sf.Rectangle()
2) Copy
In the official binding, there are plenty of copy() methods to make copies but in Python copies are done via the copy module.
In my binding instead of writing:
image = sf.Image.load_from_file("myimage.png")
image2 = image.copy()
You write:
from copy import copy, deepcopy
image = sf.Image.from_file("myimage.png")
image2 = copy(image)
3) C++ multiple definitions are not emulated
In Python, there are no multiple definitions. Instead of emulating this C++ feature and make Python functions take any argument then check whether they match a C++ function definition, I split functions.
For example, instead of writing this:
texture.update(window)
texture.update(image)
You write:
texture.update_from_window(window)
texture.update_from_image(image)
Another typical example is with multiple constructors. Here are the C++ Shader constructors.
bool loadFromFile (const std::string &filename, Type type
bool loadFromFile (const std::string &vertexShaderFilename, const std::string &fragmentShaderFilename)
Instead of writing this:
shader = sf.Shader.load_from_file("vertex.vert", "fragment.frag")
vertex = sf.Shader.load_from_file("vertex.vert", sf.Shader.VERTEX)
fragment = sf.Shader.load_from_file("fragment.frag", sf.Shader.FRAGMENT)
In my binding, you write:
shader = sf.Shader.from_file("vertex.vert", "fragment.frag")
vertex = sf.Shader.from_file(vertex="vertex.vert")
fragment = sf.Shader.from_file(fragment="fragment.frag")
4) Methods/function's name more pythonic.
The standard Python library traditionally uses from_foo() and to_bar() to respectively load/open and save objects. The binding does that as well.
music = sf.Music.from_file() # pythonic
music = sf.Music.open_from_file() # less pythonic
5) All of SFML's native classes are found.
You don't find Window, VertexArray and probably others in Bastien's binding.