Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Messages - Kaoron

Pages: [1]
1
Python / pysfml2-cython
« 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 !

2
General discussions / SFML 2.0
« on: November 10, 2010, 08:47:18 pm »
Quote from: "Groogy"
Quote from: "Kaoron"
Torvalds himself likes to control everything

 I like how you address him like if he's a deity...

Haha, he might not be a deity, but as far as I know of him, he's known to be 3 things :
 - the creator and maintainer of linux, and the only person who can commit to the official linux repo
 - the creator of git
 - a lucky bastard

He has (and keeps) control on just everything goes in one of the biggest software project ever. And he created and uses git for it. Dare to come and say that git is not suited because you want to keep control on your project. :P

Quote from: "Groogy"
If someone came and made a complete new branch out of the Ruby bindings I would probably be a bit pissed. If someone wants to contribute or even so do a huge change on my project, it would be nice if they asked first..

svn does not prevent forks, neither wild huge contributions. svn does not force developers to get in touch with maintainers before doing what they want.
There's no more control with a centralized vcs than with a distributed one.
The only thing svn prevents is contributors to have their work be version controlled, they have to get commit access to the official repo or set-up their own vcs. The former is less control because you have to trust someone enough to give him commit access, both are tedious.

Quote from: "Groogy"
Also if they go so far to actually wanting to merge their branch with the original then I would say absolutely no. I would have no idea of what they've done to the project. They might have gone against some of my personal rules when it comes to programming and etc. etc. The issues are endless when it comes to programmers interacting :D.

I'd say no too, and it's arguably a good answer to that kind of contribution. But there's nothing here that advantages svn over git or hg. That's necessary and inevitable community management, traditionnaly done through some file aimed at developers which gives them enough keys to avoid making a faux-pas.

Quote from: "Groogy"
Using TortoiseSVN makes everything easy and suits my needs. Well at least on Windows. So I work with the Ruby bindings on a Virtual Machine Ubuntu installation but commit trough Windows XD

I understand that and I don't want to force anyone, but there was some prejudices on distributed vcs that couldn't stay uncorrected. ;)

3
General discussions / SFML 2.0
« on: November 10, 2010, 08:16:55 am »
Quote from: "Laurent"
I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.

However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here :)

I'm quite late, but I'd answer that you're absolutely not forced to do more community management with git/hg than you do with svn, neither do you lose control on what happens (Torvalds himself likes to control everything).
Distributed vcs brings version control to contributors without having them hit the official repo. Imo it's a good thing − look at what happens on the python binding, bastien couldn't hit the svn repo, so he went for mercurial… all in all, version control is needed and contributors contribute.
Regarding huge contribs, just do as you would do with any other vcs stuff : refuse patches that are too big or not debated enough, write a HACKERS file to explain how you want contributions to happen, do the merging stuff yourself and control everything if you want to. A lot of developpers have the same feelings as you about their project, distributed vcs just works fine.  

Quote from: "phear-"
Not to mention that I hated using Git in my last project...

You should give it another try, it's not that terrible and it's really worth it.

4
Python / Python binding generation tools
« on: November 07, 2010, 09:01:17 am »
Quote from: "bastien"
Do you you think I should keep constants this way or place them in namespaces like SFML does?


Code: [Select]
python -c "import this" | tail -n 1  :D

Also, what about renaming the module to pysfml ? I never liked the ugly PySFML.sf import, ans as we have import aliases in python, there's no need to abbreviate it's name to sf.

5
Python / Python binding generation tools
« on: November 05, 2010, 08:16:06 am »
Quote
But how would I, as the user, know that?

Try. Fail. Accept the new convention. ???. Profit.

Edit : One thing I've been stuck onto with cython is wrapping existing C++ instances (like one returned by a function/method). bastien, did you try to implement a method such as VideoMode::GetMode ?

Edit : Oh, and - care : your indentation is done with 5 spaces instead of 4. Baaad. :P

6
Python / Image.Smooth() broken?
« on: November 01, 2010, 09:54:26 am »
Hi guys. Didn't Tank project to port pysfml to boost.python ? Have news from him ?

Not a big fan of SWIG either, I had to deal with a poorly ported lib some time ago, the binding was buggy, and fixing the swig stuff manually was just awful.

Edit : you could also consider Cython/Pyrex which looks more pythonic and seems to have better perfs than boost/SWIG, however it looks more friendly with C than C++

Oh, and this comparison on wrapping methods is interesting.

7
Python / Threading PySFML (Tank, remi, anyone familiar with GIL ? )
« on: April 15, 2010, 01:42:29 am »
This is a follow-up of a thread (!) in the french forum :
http://www.sfml-dev.org/forum-fr/viewtopic.php?t=2454

Basically, it says "PySFML locks all threads up".
I first investigated on how to work around this limitation on the python side, resulting in the use of sleep() inside the PySFML thread - maybe any IO function could do the trick here.

Now, I wish to make the wrapper more thread-friendly, there comes the GIL, the (in)famous Global Interpreter Lock. To let python threads execute while pysfml is doing time consuming IO stuff (like say... displaying things), the module has to release the lock so it is on it's own, then reacquire it when it wants to discuss with python again.

I made a test wrapping the Display call between python ALLOW_THREADS macros, but I don't have a very deep understanding on how the GIL works, and how extension modules can be safely threaded.

Here is the trick (in Window.cpp) :
Code: [Select]
static PyObject *
PySfWindow_Display(PySfWindow *self)
{
    Py_BEGIN_ALLOW_THREADS
    self->obj->Display();
    Py_END_ALLOW_THREADS
    Py_RETURN_NONE;
}


Pretty simple, isn't it ? Yet maybe awfully stupid regarding concurrent programming design, so that's the very rationale of this topic : let's discuss it to make sure what's the way to go.

8
Python / PySFML2
« on: April 13, 2010, 03:31:03 pm »
I didn't work on sf::Renderer, but here is another patch which covers a few renamings since my last post, plus a fix in Window.cpp presented here.

Code: [Select]
Index: src/Shape.cpp
===================================================================
--- src/Shape.cpp (révision 1509)
+++ src/Shape.cpp (copie de travail)
@@ -237,9 +237,9 @@
 }
 
 static PyObject *
-PySfShape_GetNbPoints(PySfShape* self, PyObject *args)
+PySfShape_GetPointsCount(PySfShape* self, PyObject *args)
 {
- return PyLong_FromUnsignedLong(self->obj->GetNbPoints());
+ return PyLong_FromUnsignedLong(self->obj->GetPointsCount());
 }
 
 static PyObject *
@@ -266,18 +266,18 @@
 Get the outline color of a point.\n Index : Index-th point."},
  {"SetPointPosition", (PyCFunction)PySfShape_SetPointPosition, METH_VARARGS, "SetPointPosition(Index, X, Y).\n\
 Set the position of a point\n\
- Index : Index of the point, in range [0, GetNbPoints() - 1]\n\
+ Index : Index of the point, in range [0, GetPointscount() - 1]\n\
  X :     New X coordinate of the Index-th point\n\
  Y :     New Y coordinate of the Index-th point."},
  {"SetPointColor", (PyCFunction)PySfShape_SetPointColor, METH_VARARGS, "SetPointColor(Index, Color).\n\
 Set the color of a point\n\

- Index : Index of the point, in range [0, GetNbPoints() - 1]\n\
+ Index : Index of the point, in range [0, GetPointscount() - 1]\n\
  Col :   New color of the Index-th point."},
  {"SetPointOutlineColor", (PyCFunction)PySfShape_SetPointOutlineColor, METH_VARARGS, "SetPointOutlineColor(Index, Color).\n\
 Set the outline color of a point\n\

- Index : Index of the point, in range [0, GetNbPoints() - 1]\n\
+ Index : Index of the point, in range [0, GetPointscount() - 1]\n\
  Col :   New color of the Index-th point."},
- {"GetNbPoints", (PyCFunction)PySfShape_GetNbPoints, METH_NOARGS, "GetNbPoints()\n\
+ {"GetPointsCount", (PyCFunction)PySfShape_GetPointsCount, METH_NOARGS, "GetPointscount()\n\
 Get the number of points composing the shape."},
  {"EnableFill", (PyCFunction)PySfShape_EnableFill, METH_O, "EnableFill(Enable)\n\
 Enable or disable filling the shape. Fill is enabled by default.\n\Index: src/Glyph.hpp
===================================================================
--- src/Glyph.hpp (révision 1509)
+++ src/Glyph.hpp (copie de travail)
@@ -36,8 +36,8 @@
  PyObject_HEAD
  bool Owner;
  int Advance;
- PySfIntRect *Rectangle;
- PySfFloatRect *TexCoords;
+ PySfIntRect *Bounds;
+ PySfIntRect *SubRect;
  sf::Glyph *obj;
 } PySfGlyph;
 
Index: src/Glyph.cpp
===================================================================
--- src/Glyph.cpp (révision 1509)
+++ src/Glyph.cpp (copie de travail)
@@ -32,8 +32,8 @@
 
 static PyMemberDef PySfGlyph_members[] = {
  {(char *)"Advance", T_INT, offsetof(PySfGlyph, Advance), 0, (char *)"Offset to move horizontically to the next character."},
- {(char *)"Rectangle", T_OBJECT, offsetof(PySfGlyph, Rectangle), 0, (char *)"Bounding rectangle of the glyph, in relative coordinates."},
- {(char *)"TexCoords", T_OBJECT, offsetof(PySfGlyph, TexCoords), 0, (char *)"Texture coordinates of the glyph inside the bitmap font."},
+ {(char *)"Bounds", T_OBJECT, offsetof(PySfGlyph, Bounds), 0, (char *)"Bounding rectangle of the glyph, in coordinates relative to the baseline."},
+ {(char *)"SubRect", T_OBJECT, offsetof(PySfGlyph, SubRect), 0, (char *)"Texture coordinates of the glyph inside the font's image."},
  {NULL}  /* Sentinel */
 };
 
@@ -41,8 +41,8 @@
 static void
 PySfGlyph_dealloc(PySfGlyph *self)
 {
- Py_CLEAR(self->Rectangle);
- Py_CLEAR(self->TexCoords);
+ Py_CLEAR(self->Bounds);
+ Py_CLEAR(self->SubRect);
  delete self->obj;
  free_object(self);
 }
@@ -51,16 +51,16 @@
 PySfGlyphUpdateObj(PySfGlyph *self)
 {
  self->obj->Advance = self->Advance;
- PySfIntRectUpdateSelf(self->Rectangle);
- PySfFloatRectUpdateSelf(self->TexCoords);
+ PySfIntRectUpdateSelf(self->Bounds);
+ PySfIntRectUpdateSelf(self->SubRect);
 }
 
 void
 PySfGlyphUpdateSelf(PySfGlyph *self)
 {
  self->Advance = self->obj->Advance;
- PySfIntRectUpdateObj(self->Rectangle);
- PySfFloatRectUpdateObj(self->TexCoords);
+ PySfIntRectUpdateObj(self->Bounds);
+ PySfIntRectUpdateObj(self->SubRect);
 }
 
 static PyObject *
@@ -70,17 +70,17 @@
  self = (PySfGlyph *)type->tp_alloc(type, 0);
  if (self != NULL)
  {
- self->Rectangle = GetNewPySfIntRect();
- self->Rectangle->Owner = false;
- self->TexCoords = GetNewPySfFloatRect();
- self->TexCoords->Owner = false;
+ self->Bounds = GetNewPySfIntRect();
+ self->Bounds->Owner = false;
+ self->SubRect = GetNewPySfIntRect();
+ self->SubRect->Owner = false;
  self->obj = new sf::Glyph();
  self->Owner = true;
  self->Advance = self->obj->Advance;
- self->Rectangle->obj = &(self->obj->Rectangle);
- self->TexCoords->obj = &(self->obj->TexCoords);
- PySfIntRectUpdateSelf(self->Rectangle);
- PySfFloatRectUpdateSelf(self->TexCoords);
+ self->Bounds->obj = &(self->obj->Bounds);
+ self->SubRect->obj = &(self->obj->SubRect);
+ PySfIntRectUpdateSelf(self->Bounds);
+ PySfIntRectUpdateSelf(self->SubRect);
  }
  return (PyObject *)self;
 }
@@ -90,8 +90,8 @@
 {
  int result = PyObject_GenericSetAttr(self, attr_name, v);
  PySfGlyph *Glyph = (PySfGlyph *)self;
- Glyph->obj->Rectangle = *(Glyph->Rectangle->obj);
- Glyph->obj->TexCoords = *(Glyph->TexCoords->obj);
+ Glyph->obj->Bounds = *(Glyph->Bounds->obj);
+ Glyph->obj->SubRect = *(Glyph->SubRect->obj);
  Glyph->obj->Advance = Glyph->Advance;
  return result;
 }
Index: src/Font.cpp
===================================================================
--- src/Font.cpp (révision 1509)
+++ src/Font.cpp (copie de travail)
@@ -106,14 +106,14 @@
  PySfGlyph*  glyph( GetNewPySfGlyph() );
 
  glyph->Owner = false;
- glyph->Rectangle = GetNewPySfIntRect();
- glyph->Rectangle->Owner = false;
- glyph->TexCoords = GetNewPySfFloatRect();
- glyph->TexCoords->Owner = false;
+ glyph->Bounds = GetNewPySfIntRect();
+ glyph->Bounds->Owner = false;
+ glyph->SubRect = GetNewPySfIntRect();
+ glyph->SubRect->Owner = false;
 
  glyph->obj = const_cast<sf::Glyph*>( &( self->obj->GetGlyph( codepoint, charsize, bold ) ) );
- glyph->Rectangle->obj = &glyph->obj->Rectangle;
- glyph->TexCoords->obj = &glyph->obj->TexCoords;
+ glyph->Bounds->obj = &glyph->obj->Bounds;
+ glyph->SubRect->obj = &glyph->obj->SubRect;
 
  PySfGlyphUpdateSelf( glyph );
 
Index: src/Rect.hpp
===================================================================
--- src/Rect.hpp (révision 1509)
+++ src/Rect.hpp (copie de travail)
@@ -33,9 +33,9 @@
  PyObject_HEAD
  bool Owner;
  int Left;
- int Right;
  int Top;
- int Bottom;
+ int Width;
+ int Height;
  sf::IntRect *obj;
 } PySfIntRect;
 
@@ -43,9 +43,9 @@
  PyObject_HEAD
  bool Owner;
  float Left;
- float Right;
  float Top;
- float Bottom;
+ float Width;
+ float Height;
  sf::FloatRect *obj;
 } PySfFloatRect;

Index: src/Rect.cpp
===================================================================
--- src/Rect.cpp (révision 1509)
+++ src/Rect.cpp (copie de travail)
@@ -33,16 +33,16 @@
 static PyMemberDef PySfIntRect_members[] = {
  {(char *)"Left", T_INT, offsetof(PySfIntRect, Left), 0, (char *)"Left coordinate of the rectangle."},
  {(char *)"Top", T_INT, offsetof(PySfIntRect, Top), 0, (char *)"Top coordinate of the rectangle."},
- {(char *)"Right", T_INT, offsetof(PySfIntRect, Right), 0, (char *)"Right coordinate of the rectangle."},
- {(char *)"Bottom", T_INT, offsetof(PySfIntRect, Bottom), 0, (char *)"Bottom coordinate of the rectangle."},
+ {(char *)"Width", T_INT, offsetof(PySfIntRect, Width), 0, (char *)"Width of the rectangle."},
+ {(char *)"Height", T_INT, offsetof(PySfIntRect, Height), 0, (char *)"Height of the rectangle."},
  {NULL}  /* Sentinel */
 };
 
 static PyMemberDef PySfFloatRect_members[] = {
  {(char *)"Left", T_FLOAT, offsetof(PySfFloatRect, Left), 0, (char *)"Left coordinate of the rectangle."},
  {(char *)"Top", T_FLOAT, offsetof(PySfFloatRect, Top), 0, (char *)"Top coordinate of the rectangle."},
- {(char *)"Right", T_FLOAT, offsetof(PySfFloatRect, Right), 0, (char *)"Right coordinate of the rectangle."},
- {(char *)"Bottom", T_FLOAT, offsetof(PySfFloatRect, Bottom), 0, (char *)"Bottom coordinate of the rectangle."},
+ {(char *)"Width", T_FLOAT, offsetof(PySfFloatRect, Width), 0, (char *)"Width of the rectangle."},
+ {(char *)"Height", T_FLOAT, offsetof(PySfFloatRect, Height), 0, (char *)"Height of the rectangle."},
  {NULL}  /* Sentinel */
 };
 
@@ -65,15 +65,15 @@
 static PyObject *
 PySfIntRect_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
 {
- const char *kwlist[] = {"Left", "Top", "Right", "Bottom", NULL};
+ const char *kwlist[] = {"Left", "Top", "Width", "Height", NULL};
  PySfIntRect *self;
  self = (PySfIntRect *)type->tp_alloc(type, 0);
  if (self != NULL)
  {
  self->Owner = true;
- if (!PyArg_ParseTupleAndKeywords(args, kwds, "iiii:IntRect.__new__", (char **)kwlist, &(self->Left), &(self->Top), &(self->Right), &(self->Bottom)))
+ if (!PyArg_ParseTupleAndKeywords(args, kwds, "iiii:IntRect.__new__", (char **)kwlist, &(self->Left), &(self->Top), &(self->Width), &(self->Height)))
  return NULL;
- self->obj = new sf::IntRect(self->Left, self->Top, self->Right, self->Bottom);
+ self->obj = new sf::IntRect(self->Left, self->Top, self->Width, self->Height);
  }
  return (PyObject *)self;
 }
@@ -81,79 +81,32 @@
 static PyObject *
 PySfFloatRect_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
 {
- const char *kwlist[] = {"Left", "Top", "Right", "Bottom", NULL};
+ const char *kwlist[] = {"Left", "Top", "Width", "Height", NULL};
  PySfFloatRect *self;
  self = (PySfFloatRect *)type->tp_alloc(type, 0);
  if (self != NULL)
  {
  self->Owner = true;
- if (!PyArg_ParseTupleAndKeywords(args, kwds, "ffff:FloatRect.__new__", (char **)kwlist, &(self->Left), &(self->Top), &(self->Right), &(self->Bottom)))
+ if (!PyArg_ParseTupleAndKeywords(args, kwds, "ffff:FloatRect.__new__", (char **)kwlist, &(self->Left), &(self->Top), &(self->Width), &(self->Height)))
  return NULL;
- self->obj = new sf::FloatRect(self->Left, self->Top, self->Right, self->Bottom);
+ self->obj = new sf::FloatRect(self->Left, self->Top, self->Width, self->Height);
  }
  return (PyObject *)self;
 }
 
 static PyObject *
-PySfIntRect_GetSize(PySfIntRect *self)
-{
- sf::Vector2i  size( self->obj->GetSize() );
- return Py_BuildValue( "ii", size.x, size.y );
-}
-
-static PyObject *
 PySfIntRect_Contains(PySfIntRect* self, PyObject *args);
 
 static PyObject *
 PySfIntRect_Intersects(PySfIntRect* self, PyObject *args);
 
 static PyObject *
-PySfFloatRect_GetSize(PySfFloatRect *self)
-{
- sf::Vector2f  size( self->obj->GetSize() );
- return Py_BuildValue( "ff", size.x, size.y );
-}
-
-static PyObject *
 PySfFloatRect_Contains(PySfFloatRect* self, PyObject *args);
 
 static PyObject *
 PySfFloatRect_Intersects(PySfFloatRect* self, PyObject *args);
 
-static PyObject *
-PySfIntRect_Offset(PySfIntRect* self, PyObject *args)
-{
- int OffsetX, OffsetY;
-
- if (!PyArg_ParseTuple(args, "ii:IntRect.Offset", &OffsetX, &OffsetY))
- return NULL;
-
- self->obj->Offset(OffsetX, OffsetY);
- PySfIntRectUpdateSelf(self);
- Py_RETURN_NONE;
-}
-
-static PyObject *
-PySfFloatRect_Offset(PySfFloatRect* self, PyObject *args)
-{
- float OffsetX, OffsetY;
-
- if (!PyArg_ParseTuple(args, "ff:FloatRect.Offset", &OffsetX, &OffsetY))
- return NULL;
-
- self->obj->Offset(OffsetX, OffsetY);
- PySfFloatRectUpdateSelf(self);
- Py_RETURN_NONE;
-}
-
-
 static PyMethodDef PySfIntRect_methods[] = {
- {"Offset", (PyCFunction)PySfIntRect_Offset, METH_VARARGS, "Offset(OffsetX, OffsetY)\n\
-Move the whole rectangle by the given offset.\n\
- OffsetX : Horizontal offset\n\
- OffsetY : Vertical offset\n\
-"},
- {"GetSize", (PyCFunction)PySfIntRect_GetSize, METH_NOARGS, "GetSize()\nGet the rectangle's size."},
  {"Contains", (PyCFunction)PySfIntRect_Contains, METH_VARARGS, "Contains(X, Y)\n\
 Check if a point is inside the rectangle's area.\n\
  X : X coordinate of the point to test\n\
@@ -167,12 +120,6 @@
 
 
 static PyMethodDef PySfFloatRect_methods[] = {
- {"Offset", (PyCFunction)PySfFloatRect_Offset, METH_VARARGS, "Offset(OffsetX, OffsetY)\n\
-Move the whole rectangle by the given offset.\n\
- OffsetX : Horizontal offset\n\
- OffsetY : Vertical offset\n\
-"},
- {"GetSize", (PyCFunction)PySfFloatRect_GetSize, METH_NOARGS, "GetSize()\nGet the rectangle's size."},
  {"Contains", (PyCFunction)PySfFloatRect_Contains, METH_VARARGS, "Contains(X, Y)\n\
 Check if a point is inside the rectangle's area.\n\
  X : X coordinate of the point to test\n\
@@ -347,36 +294,36 @@
 PySfIntRectUpdateObj(PySfIntRect *self)
 {
  self->obj->Left = self->Left;
- self->obj->Right = self->Right;
  self->obj->Top = self->Top;
- self->obj->Bottom = self->Bottom;
+ self->obj->Width = self->Width;
+ self->obj->Height = self->Height;
 }
 
 void
 PySfFloatRectUpdateObj(PySfFloatRect *self)
 {
  self->obj->Left = self->Left;
- self->obj->Right = self->Right;
  self->obj->Top = self->Top;
- self->obj->Bottom = self->Bottom;
+ self->obj->Width = self->Width;
+ self->obj->Height = self->Height;
 }
 
 void
 PySfIntRectUpdateSelf(PySfIntRect *self)
 {
  self->Left = self->obj->Left;
- self->Right = self->obj->Right;
  self->Top = self->obj->Top;
- self->Bottom = self->obj->Bottom;
+ self->Width = self->obj->Width;
+ self->Height = self->obj->Height;
 }
 
 void
 PySfFloatRectUpdateSelf(PySfFloatRect *self)
 {
  self->Left = self->obj->Left;
- self->Right = self->obj->Right;
  self->Top = self->obj->Top;
- self->Bottom = self->obj->Bottom;
+ self->Width = self->obj->Width;
+ self->Height = self->obj->Height;
 }
 
 PySfIntRect *
 


TODO :
- Complete my previous patch with a proper Renderer wrapper
- Fix changes in VideoMode (-GetMode, -GetModesCount, +GetFullscreenModes)
- maybe some other changes I didn't notice

It would also be nice to fix fileformats inconsistencies : some files are unix, some are dos. Newlines are often messed up in patches.

9
Graphics / SetScale in 1.6 displaces the graphics
« on: April 11, 2010, 11:40:00 am »
Quote
That's exactly what I've been working on since last week, actually Wink
...
It's not going to happen in SFML 2. I will strictly follow the usual rules: minor versions (2.x) will be API backward-compatible, and patch versions (2.x.y) will be binary backward compatible. If any modification needs to break the public API then it will be postponed to SFML 3, or there will be a workaround to make the old version still work.

Glad to read this, I wish a long compatible life to sfml2 :)

Quote
There will be a list of what was modified/rewritten, but not a list of all the symbols that were removed. People will really need to read the new documentation and tutorials. It won't be just a matter of replacing/removing the deprecated symbols in your code, you will have to adapt to the new design of the API.
Well, that was the idea. One could grep for any modified/removed symbol in his code base to easily find the spots that need to be recrafted, taking care of the big red warning heading the new tutorials.
Good code with careful encapsulation of sfml shouldn't be hard to migrate, but I bet there will be a lot of blood, tears and pain for the others.  :twisted:

Quote
It's not just a problem of version number, to fix this bug I'll have to modify the rendering process and that will potentially break other things, I can't release a new version until I get enough feedback.

It's understandable.
You seemed shocked to find out that this bug wasn't fixed yet, isn't there a way to add a "1.6 release-critical" flag in flyspray ?

10
Graphics / SetScale in 1.6 displaces the graphics
« on: April 11, 2010, 09:57:29 am »
//topic hijacking in progress
Quote from: "Laurent"
Quote
Ok, can't you just update the 1.6 version with the fix or something?

I would have to make a new release with a new version number. It's not that easy, actually.

Ease it, actually. Postponing trivial but annoying bugfixes to the next major API destroyer release because of the version number incrementation toughness is ludicrous, and I am sure you're ashamed of it. Please find a way to drop this ball and chain and free the 1.6.01-oopsireleasedtooearly version number.

Quote from: "Laurent"
I'm currently thinking about releasing SFML 2.0 "soon", a lot of planned features can be added in a future minor release of SFML 2.

Is the API rock-hard enough to survive the whole sfml2 branch lifetime ? I'll never stop bothering you with this, hacking from time to time inside the python binding because of an API break from GetSize to GetBounds is bearable in the early stages of a major release, but thereafter should not happen 'till the next one (instead, you should provide a deprecation mechanism).
This may be a bearable annoyance for windows developers which are used to ship third-part libraries with their software and can stick to an obsolete version, but linux developers heavily rely on libraries shipped with the system. Breaking every six month populates distros with incompatible (hear unreliable) versions of the lib. This is a killer.

Plus, I lost the count of every API-breaking changes between sfml1 and sfml2, will there be a list of every deprecated (yet pruned) symbols and functions ?

Apart of this you're doing great job as usual, and I feel guilt for such a harsh posting. Keep up the good work !

11
Python / 1.6 python release?
« on: April 10, 2010, 05:04:11 pm »
trunk is ok, you should go for it.

12
Python / [PySFML/pygtk] RenderWindow from handle (patch+snippet)
« on: April 06, 2010, 03:52:52 pm »
Hi, I'm trying to integrate a RenderWindow to a Gtk widget, but it looks like it doesn't work with PySFML. I had to modify Window.cpp to get this OK.

Here is my mods to python/src/Window.cpp :

Code: [Select]
Index: src/Window.cpp
===================================================================
--- src/Window.cpp (révision 1509)
+++ src/Window.cpp (copie de travail)
@@ -144,6 +144,26 @@
  Py_RETURN_NONE;
 }

+static PyObject *
+PySfWindow_CreateFromHandle(PySfWindow* self, PyObject *args, PyObject *kwds)
+{
+    long Handle;
+    PySfContextSettings *Params=NULL;
+ if (self != NULL)
+ {
+    if (!PyArg_ParseTuple(args, "l|O!:Window.__new__", &Handle, &PySfContextSettingsType, &Params))
+        return NULL;
+    if (Params)
+    {
+    PySfContextSettingsUpdate(Params);
+    self->obj->Create((sf::WindowHandle)Handle, *(Params->obj));
+    }
+    else
+    self->obj->Create((sf::WindowHandle)Handle);
+ }
+ Py_RETURN_NONE;
+}
+
 static int
 PySfWindow_init(PySfWindow *self, PyObject *args, PyObject *kwds)
 {
@@ -155,7 +175,10 @@
  if (PyTuple_Size(args) == 0)
  return 0;
  if (PyArg_ParseTuple(args, "l|O!:Window.__new__", &Handle, &PySfContextSettingsType, &Params))
+ {
+ PySfWindow_CreateFromHandle(self, args, kwds);
  return 0;
+ }
  PyErr_Clear();
  if (PySfWindow_Create(self, args, kwds) == NULL)
  return -1;
@@ -315,6 +338,7 @@
  Title : Title of the window\n\
  WindowStyle : Window style (Resize | Close by default)\n\
  Params : Creation parameters (see default constructor for default values)"},
+ {"CreateFromHandle", (PyCFunction)PySfWindow_CreateFromHandle, METH_VARARGS, "CreateFromHandle(Handle)\nCreate a window using the given native ID"},
  {"Display", (PyCFunction)PySfWindow_Display, METH_NOARGS, "Display()\nDisplay the window on screen."},
  {"EnableKeyRepeat", (PyCFunction)PySfWindow_EnableKeyRepeat, METH_O, "EnableKeyRepeat(Enable)\nEnable or disable automatic key-repeat. Automatic key-repeat is enabled by default.\n Enabled : True to enable, false to disable"},
  {"GetEvent", (PyCFunction)PySfWindow_GetEvent, METH_O, "GetEvent(Event)\nGet the event on top of events stack, if any, and pop it. Returns True if an event was returned, False if events stack was empty.\n EventReceived : Event to fill, if any."},


and here is a pygtk+pysfml snippet :

Code: [Select]
import gtk, gobject
from PySFML import sf
class SFMLWidget(gtk.DrawingArea):
    def __init__(self):
        gtk.DrawingArea.__init__(self)
        self.connect("realize",self.realize)
        self.connect("unrealize",self.unrealize)
    def realize(self, event):
        self.set_double_buffered(False)
        self.sfml_canvas = sf.RenderWindow(self.window.xid)
    def unrealize(self,event):
        self.sfml_canvas.Close()


def main():
    window = gtk.Window()
    widget = SFMLWidget()

    window.add(widget)
    window.connect("destroy", gtk.main_quit)
    window.show_all()
    def display():
        print "Display"
        widget.sfml_canvas.Clear()
        widget.sfml_canvas.Display()
        return True
    display_tag = gobject.timeout_add(5,display)

    gtk.main()

if __name__ == "__main__":
    main()

13
Python / PySFML2
« on: February 17, 2010, 02:42:38 am »
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;

14
Python / PySFML2
« on: February 17, 2010, 02:01:58 am »
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)

Pages: [1]