61
General discussions / Re: SFML team is growing
« on: August 05, 2013, 10:36:26 pm »French guys already rule the world, but no one knows it !
I was told it was Chinese people lol
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I was told it was Chinese people lol
62
General discussions / Re: Debian/Ubuntu packages for SFML
« on: August 05, 2013, 07:43:12 pm »
Haha, thank you! 
(that's how I thank SFML for being what it is ;p). More seriously, packaging SFML came from a personal need so.. it's a pleasure for me to share this work.
(that's how I thank SFML for being what it is ;p). More seriously, packaging SFML came from a personal need so.. it's a pleasure for me to share this work.
63
General discussions / Re: SFML team is growing
« on: August 05, 2013, 07:34:19 pm »
Thanks everyone!
I'm proud to join the SFML team and I'll do my best to give you an awesome experience of SFML on Android! I'll be happy to bring any interesting libraries and bindings into the Linux repositories, so I might contact some of you soon about that In a later stage, I won't mind packaging games or software so don't hesitate to ask me!
Thanks again!
I'm proud to join the SFML team and I'll do my best to give you an awesome experience of SFML on Android! I'll be happy to bring any interesting libraries and bindings into the Linux repositories, so I might contact some of you soon about that
In a later stage, I won't mind packaging games or software so don't hesitate to ask me!Thanks again!
64
General discussions / Re: Debian/Ubuntu packages for SFML
« on: August 04, 2013, 05:05:48 pm »
Sorry, it wasn't clear at all. As Ubuntu repositories are frozen at each release and as its next version is scheduled for release on 17 October 2013, I preferred to focus on Fedora packages first. This time, it will include the C and .Net bindings and an effort will be make for the unofficial ones (Python, Java, Ruby). Note that they're all already packaged for Fedora and are being reviewed at the moment. The launchpad repository will remain to bring the latest version of SFML and its bindings to older Debian/Ubuntu versions.
65
General discussions / Re: Debian/Ubuntu packages for SFML
« on: August 04, 2013, 01:43:57 am »Any progress in adding SFML 2.1 to debian repos? It would be great because that would make it available on a big part of linux world because many widely used distros are based on debian repos.SFML is getting its own repository.
I should give news by the end of the (next) week.I actually do have libglew 1.7 installed, but i don't get, why dpkg does not want to use it.I'll give a try on Debian 7.1 as soon as I can.
The libc6 2.13-38 seems to be the newest version for debian 7.1 .
67
Python / Re: How to install ubuntu 12.04 on PySFML (Python3.3.2)
« on: August 01, 2013, 06:03:55 pm »
Download pySFML from https://github.com/Sonkun/python-sfml . because you've downloaded the wrong Python bindings.
68
General discussions / Re: Debian/Ubuntu packages for SFML
« on: July 27, 2013, 03:59:52 am »
Unfortunately, I haven't tried on Debian so I can't really help here but, from what I can see, the repo is properly added but Debian isn't looking for the packages at the right place. It expects to find them under dist/wheezy but it'll only find some under dist/precise, dist/quantal and dist/raring so try a manual install. Remove the repo you just added, download the .deb packages and "dpkg -i sfml*.deb".
https://launchpad.net/~sonkun/+archive/sfml-stable
https://launchpad.net/~sonkun/+archive/sfml-stable
69
Python / Re: Somes problems with sf.Event
« on: July 21, 2013, 06:24:50 am »
I just answered on the French forum: http://fr.sfml-dev.org/forums/index.php?topic=12244.0
I guess I'll give feedbacks here once this issue is solved.
I guess I'll give feedbacks here once this issue is solved.
70
Python / Re: sf.Vector2(sf.Vector2) create some problems
« on: July 12, 2013, 04:52:45 pm »
The sf.Vector2 constructor takes x and y, the two being optional and defaulted to 0. So if you write sf.Vector2(a) with a being a sf.Vector2, you'll get a as x. What you need to do is, unpacking a.
Or shorter:
Good luck!
x, y = a
newVector = sf.Vector2(x, y)
newVector = sf.Vector2(x, y)
Or shorter:
newVector = sf.Vector2(*a)
Good luck!
71
Python / Re: cx_freeze pySFML compilation AttributeError, no attribute Rectangle
« on: July 05, 2013, 11:56:09 pm »
Don't worry, we'll fix that If you had cx_freeze working with Bastien's bindings, then there's no reason we can't make it work since both bindings use Cython.
If you had cx_freeze working with Bastien's bindings, then there's no reason we can't make it work since both bindings use Cython.
72
Python / Re: cx_freeze pySFML compilation AttributeError, no attribute Rectangle
« on: July 05, 2013, 10:52:47 pm »
I'll check that as soon as I'm on Windows
73
Python / Re: Transformation issue
« on: July 05, 2013, 10:50:18 pm »
I forgot to implement the __copy__ method of sf.RenderStates. Try a manual copy and tell me if it works:
Thanks for reporting this bug
def copy_renderstates(renderstates):
ret = sf.RenderStates()
ret.blend_mode = renderstates.blend_mode
ret.shader = renderstates.shader
ret.texture = renderstates.texture
ret.transform = renderstates.transform
return ret
ret = sf.RenderStates()
ret.blend_mode = renderstates.blend_mode
ret.shader = renderstates.shader
ret.texture = renderstates.texture
ret.transform = renderstates.transform
return ret
Thanks for reporting this bug
74
General discussions / Re: SFML Game Development -- A book on SFML
« on: June 25, 2013, 10:26:16 pm »
Amazing! Congratulation, all of you! 
I'll buy it at Fnac and will ask the guy to order 3 or 4 more for other people. Of course, I'll take care to put them on the front during my next visit 
I'll buy it at Fnac and will ask the guy to order 3 or 4 more for other people. Of course, I'll take care to put them on the front during my next visit
75
Python / Re: Somes problems with sf.Event
« on: June 20, 2013, 12:21:43 am »
Weird. Renaming its name has solved everything on my computer... :/ Actually, when a Window2 object is destroyed, since it inherits from sf.Window, the sf.Window destructor is called and deletes the internal C++ object IF the class name is "Window". The original purpose of that is to separate the sf.Window and sf.RenderWindow destructor behavior, the first destroying sf::Window and the second destroying sf::RenderWindow.
I need to rework the inheritance implementation (which isn't straight forward, no documentation or official how-to). One of the remaining task before the next version (1.4) is the investigation of the usage of smart C++ pointer which might be a solution to that issue.
I need to rework the inheritance implementation (which isn't straight forward, no documentation or official how-to). One of the remaining task before the next version (1.4) is the investigation of the usage of smart C++ pointer which might be a solution to that issue.