Author Topic: pysfml-cython (Read 102339 times)

bastien · « **Reply #15 on:** August 19, 2011, 08:08:07 pm »

I updated the binding, it should work correctly now. The documentation isn't updated yet.

Quote from: "lattyware"

Just as a note, I recently discovered you can't load images before the window is created, or the images show up as solid white instead of the image. Not sure if this is intentional or a bug, but it's not consistant with the old bindings, and I spend quite some time figuring out what the issue was, while porting across a project from the old bindings, so it might be worth noting this in the binding's docs.

Thanks, I'll test that.

lattyware · « **Reply #16 on:** August 22, 2011, 05:23:00 am »

Quote

File "sf.pyx", line 1773, in sf.Sprite.__cinit__ (sf.cpp:19704)
TypeError: Argument 'texture' has incorrect type (expected sf.Texture, got sf.Image)

Now getting this error with the updated bindings, both Linux and Windows.

Edit: I see this is an intentional change. Might want to update the docs.

I tried replacing:

Code: [Select]

self.sprite.set_image(image, True)

with:

Code: [Select]

self.sprite.texture = texture
self.sprite.resize(texture.width, texture.height)

But the resize does not appear to work.

(Just as I finish my Ludum Dare entry >.>)

Also, if you didn't see my last edit, I found it wasn't the order, but rather that the sprite doesn't act as a reference to the image. So you can't do sf.Sprite(sf.Image.load_from_file("blah.jpg")) as the image will not be kept in memory, which you could do in the 1.6 bindings.

Not a bug, but as I say, worth noting as it might catch people out.

bastien · « **Reply #17 on:** August 24, 2011, 06:10:52 pm »

Ah, sorry. It should work now, except that it's set_texture().
I will change Sprite to keep a reference to the texture, and I will probably also change all classes where it's possible. I want to avoid problems if SFML changes the C++ object internally, but maybe I'm just paranoid. :?

bastien · « **Reply #18 on:** August 24, 2011, 06:40:11 pm »

New URL for the documentation: http://pysfml2-cython.readthedocs.org/

lattyware · « **Reply #19 on:** August 25, 2011, 05:26:09 pm »

Quote from: "bastien"

Ah, sorry. It should work now, except that it's set_texture().
I will change Sprite to keep a reference to the texture, and I will probably also change all classes where it's possible. I want to avoid problems if SFML changes the C++ object internally, but maybe I'm just paranoid. :?

Cheers for all the effort. It's entirely up to you if you want to keep the reference or not, I'd just reccomend adding a note to the docs if it doesn't, as it's not standard python behaviour, and not how the bindings used to work. It's not exactly hard to work around if you know it's there.

.teri · « **Reply #20 on:** September 05, 2011, 12:04:24 pm »

Quote from: "bastien"

Ah, sorry. It should work now, except that it's set_texture().
I will change Sprite to keep a reference to the texture, and I will probably also change all classes where it's possible. I want to avoid problems if SFML changes the C++ object internally, but maybe I'm just paranoid. :?

Always is necessary keep a reference when a class use another class in a binding, like sf::Sound with sf::SoundBuffer or sf::Sprite and sf::Texture.

Rukiri · « **Reply #21 on:** October 03, 2011, 02:06:05 am »

I don't know why but I keep getting, no module named SF.

I've installed PYSFML perfectly and got the egg info, and placed all the include and libs where they needed to be. I even tried tricking python with the pythonpath.

I've spoken to a few others and they've been having a hard time getting python to work with sfml.

I also keep getting unrecognized command line option -mno-cygwin

bastien · « **Reply #22 on:** October 03, 2011, 07:27:06 pm »

Just to be sure, are you using this binding on Github or the official PySFML binding on sfml-dev.org?

Sadly, my Windows installation doesn't work anymore, and I don't really know when I'll be able to reinstall it, so I can't really test it on Windows. :?

Rukiri · « **Reply #23 on:** October 04, 2011, 01:41:51 am »

I got it from the github, there's errors like crazy. I'm actually installing fedora 15 because of this headache..

I wonder if your binding was generally for linux? as the mno thing comes only in linux.. I got ruby working so it has to be the binding..

I tried both versions and didn't get either to work.

bastien · « **Reply #24 on:** October 04, 2011, 04:24:45 am »

I develop on GNU/Linux, but I could build and run the examples on Windows without any problem.
Normally it's pretty straightforward to build it with MinGW. You build SFML 2 first, then you add the SFML headers and libs to the corresponding folders of MinGW. Then you should be able to build pysfml2-cython with a command-line like python setup.py build_ext --inplace --compiler=mingw32.
Then you should have the module built in the current directory.

To test it quickly you can cd to the examples directory and type “PYTHONPATH=..” and then execute some of them (for the pong and shaders examples, it's PYTHONPATH=..\.. of course). Or just import sf from the command line and create a window or something.

Rukiri · « **Reply #25 on:** October 04, 2011, 05:27:53 am »

This is the one thing I can't fix.. anything GCC or MinGW related works fine but -mno-cgywin doesn't..

bastien · « **Reply #26 on:** October 04, 2011, 06:19:18 pm »

The bug has been reported, actually: http://bugs.python.org/issue12641

A quick fix would be to edit the distutils/cygwinccompiler.py file in your Python installation to remove the -mno-cygwin option. Here in the Python repo: http://hg.python.org/cpython/file/f39b26ca7f3d/Lib/distutils/cygwinccompiler.py#l294

bastien · « **Reply #27 on:** October 06, 2011, 09:30:22 pm »

I just added some support for the WindowHandle class, which required some ugly cast between integers and pointers. It compiles on GNU/Linux, but please let me know if you encounter a problem on Windows or Mac, since the WindowHandle will behave differently there.
Also, let me know if you actually use the window handle with Python programs, so we can see if I can make interaction with system-specific APIs easier.

Kaoron · « **Reply #28 on:** October 11, 2011, 11:23:46 am »

Hey, glad to see your python binding is still alive and up to date !

Just a little naming issue i think : sf looks like a very short name to import for a module, it looks collision-prone and is not very informative on the library used at first glance (what does sf stands for ? sfml ? sourceforge ? soundfile ? somefoo ?).

I'd think pysfml would be a better name to import, letting users shortcut to sf if they want.

Thanks for your work !

bastien · « **Reply #29 on:** October 12, 2011, 02:12:35 am »

It's because both C++ SFML and PySFML 1.x use sf as the namespace.
You're right that it's probably not the best module name, but I'm still reluctant to change it, as everyone is used to sf.

If I changed the name, it would probably simply be sfml though. The “py” is redundant for a Python module.