PySFML2

[Tank]

Hey,

is it possible for the maintainer to close up to SFML2? I did the most stuff myself, but got stuck with sf::SoundStream::OnSeek(), which is pure virtual.

[Tank]

By the way, who does maintain it? Maybe I could get in touch with that person.

[remi.k2620]

I maintained pysfml up to 1.5 but i didn't start pysfml2 yet (i'm quite busy in engineering school). Any help is apreciated.
Virtual functions are a bit tricky to implement, you can have a look in the already implemented virtual functions of soundstream, it should be more or less the same for onseek.

[Tank]

Nice to meet.

Okay great, thank you for the pointer. If you like I can send you a patch when I'm done, so you can look over and probably apply it.

[remi.k2620]

Yes, or maybe Laurent can give you write access to the svn, it will be easier to follow the development and make modifications this way.

[Laurent]

Yep, I can do that if you want to actively support the development of PySFML.

[Tank]

Thanks guys, I would be glad to help you out with the Python port.

[Laurent]

You must create an account on sourceforge.net, then send me your username

[Tank]

I thought it would maybe be interesting for Python developers to get some news on how the Python binding progresses. So here it is, the first update.

PySFML is now compatible with SFML2. Keep in mind that a lot of new features that have been introduced in SFML2 are still missing, hence why it's called "compatible", not synchronized. However I think it's possible to get PySFML close to the current SFML2 state shortly.

[Laurent]

Wow, that's great!

I'm so glad that this binding is still alive :lol:

[Tank]

Finally I got some time to adjust PySFML2. It currently compiles again with the latest SFML2 revision. The OpenGL sample is still broken, though.

Also sf::Image::SetSmooth() and sf::Image::Copy() are not working. This will be fixed with the next revision.

[Kaoron]

PySFML rev 1403 does not seem to compile against the latest SFML revision, but rather against some old revision which did not include the new rendering process. (RenderQueue is dead, there's a new Renderer... and some other stuff)
http://www.sfml-dev.org/forum/viewtopic.php?t=2063

Code: [Select]

In file included from src/Drawable.cpp:25:
src/Drawable.hpp:31:41: error: SFML/Graphics/RenderQueue.hpp: Aucun fichier ou dossier de ce type
In file included from src/Drawable.hpp:34,
                 from src/Drawable.cpp:25:
src/RenderQueue.hpp:35: error: ISO C++ forbids declaration of ‘RenderQueue’ with no type


(Damn, I had a mostly up-to-date local version... didn't check your commit, removed the files, shoud definitely learn how to branch locally with svn)

[Kaoron]

Not a big issue to get it compile in the end, here is the patch (you may want to check I did not do anything stupid :wink: ) :

Code: [Select]

Index: src/Drawable.cpp
===================================================================
--- src/Drawable.cpp (révision 1404)
+++ src/Drawable.cpp (copie de travail)
@@ -31,10 +31,10 @@
 extern PyTypeObject PySfColorType;
 
 
-void CustomDrawable::Render(sf::RenderTarget& Target, sf::RenderQueue& Queue) const
+void CustomDrawable::Render(sf::RenderTarget& Target, sf::Renderer& Renderer) const
 {
  if (RenderFunction)
- PyObject_CallFunction(RenderFunction, (char *)"OO", RenderWindow, Queue);
+ PyObject_CallFunction(RenderFunction, (char *)"OO", RenderWindow, Renderer);
  else
  {
  PyErr_SetString(PyExc_RuntimeError, "Custom drawables must have a render method defined");
Index: src/Drawable.hpp
===================================================================
--- src/Drawable.hpp (révision 1404)
+++ src/Drawable.hpp (copie de travail)
@@ -28,15 +28,15 @@
 #include <Python.h>
 
 #include <SFML/Graphics/Drawable.hpp>
-#include <SFML/Graphics/RenderQueue.hpp>
+#include <SFML/Graphics/Renderer.hpp>
 
 #include "RenderWindow.hpp"
-#include "RenderQueue.hpp"
+//#include "Renderer.hpp" TODO
 
 class CustomDrawable : public sf::Drawable
 {
 protected :
- virtual void Render(sf::RenderTarget& Target, sf::RenderQueue& Queue) const;
+ virtual void Render(sf::RenderTarget& Target, sf::Renderer& Renderer) const;
 public :
  PySfRenderWindow *RenderWindow;
  PyObject *RenderFunction;

[Tank]

Thanks for the patch. I'll look into it and apply it when everything's fine.

Edit: Sorry, but this can't be applied. When someone writes a new class derived from sf::Drawable, he or she must be able to work with sf::Renderer. That means a new Python wrapper must be written for it.

[leo2urlevan]

Hello
I have the same problem and can't compile it from the svn... There is an issue with "RenderQueue" too. How did you fix that ?