[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] SDL_gfx integration



I think I was wrong ... I don't remember what I was thinking. :)

Anyway, the next major version of pygame already has sdl_gfx
integrated I think, so this might be moot. :(

On Sun, Nov 9, 2008 at 5:57 AM, Lorenz Quack <don@xxxxxxxxxxxxxxxxx> wrote:
> Hi Forrest,
>
> sorry for being silent so long.
> Anyway, I don't think that my version creates a memory leak. And if it does then so does the original version, IMHO.
> The way I see it the PyArg_ParseTuple doesn't INCREF the refcount on any of the parameters so there is no need to DECREF on either "points" nor its content.
> The only things that need to be DECREFed are the "x-/ylist" and the individual "item" extracted from "points" via PySequence_GetItem which returns a new Reference
> according to the docs (http://docs.python.org/c-api/sequence.html) and I do that if there is an error before returning the exception.
>
> If I'm missing something about the refcounting and I DO have a memory leak then doesn't the same memory leak apply to the original implementation in case the very first
> point isn't a sequence of two ints (which is for some reason special-cased)?
>
> yours
> //Lorenz
>
>
> Forrest Voight wrote:
>> If there's an error, points past the bad point aren't deref'd.
>>
>> On Thu, Oct 30, 2008 at 7:24 AM,  <don@xxxxxxxxxxxxxxxxx> wrote:
>>> Hi Forrest,
>>>
>>> could you tell me how exactly my version leaks and which variable is leaking? I don't see it.
>>>
>>> I also think that vert/horiz lines could be dropped.
>>>
>>> //Lorenz
>>>
>>>
>>>
>>> On Mon, 27 Oct 2008 23:03:32 -0400, "Forrest Voight" <voights@xxxxxxxxx> wrote:
>>>> Lorenz: the polygon function is almost a direct copy from draw.c and
>>>> your way creates a memory leak if there is an error in a point past
>>>> the first one.
>>>>
>>>> I think we should just remove the vert/horiz lines... just use line.
>>>>
>>>> On Mon, Oct 27, 2008 at 10:21 AM, James Hancock <JLHancock@xxxxxxxxx>
>>>> wrote:
>>>>> A year(or two) ago I found sdl-gfx when I was trying to find ways to get
>>>>> anti-aliased circles( I worked on GASP, a beginners game creating api).
>>>> My
>>>>> understanding  then was sdl-gfx was licensed GPL so pygame could not use
>>>> it.
>>>>> I just checked and now it is LGPL. Yay :)
>>>>>
>>>>> http://www.ferzkopp.net/joomla/content/view/19/14/
>>>>>
>>>>> I talked with Andreas back than and it seemed like he was willing to
>>>> help
>>>>> the pygame community with integration and possible future work. His
>>>> email is
>>>>> on the site mentioned above. I would love to see pygame take advantage
>>>> of
>>>>> some of his work. Good luck, It looks like the ball is already started
>>>> on
>>>>> this one so lets keep moving forward
>>>>>
>>>>> Cheers!
>>>>> James Hancock
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Oct 26, 2008 at 4:34 PM, Lenard Lindstrom <len-l@xxxxxxxxx>
>>>> wrote:
>>>>>> Here are some more suggestions for the horizontal_line/vertical_line
>>>>>> issue. Since they take integer positions I can think of two
>>>> alternatives to
>>>>>> "(surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)". The
>>>> first
>>>>>> is to have no horizontal_line and vertical_line. Hide the the calls to
>>>> the
>>>>>> hlineRGBA and vlineRGBA gfx functions in the generic line function. A
>>>> few
>>>>>> extra tests to determine if a line is horizontal or vertical probably
>>>> won't
>>>>>> add much additional overhead to a Python function call. The other
>>>>>> alternative is to use a start, length approach: (surface, (x1, y1),
>>>> length,
>>>>>> color). The length can be negative. This keeps the signature consistent
>>>> for
>>>>>> both the horizontal and vertical line functions.
>>>>>>
>>>>>> Lenard
>>>>>>
>>>>>> Lorenz Quack wrote:
>>>>>>> Thanks a lot!
>>>>>>>
>>>>>>> I just looked through your patch and I have some remarks:
>>>>>>>
>>>>>>>
>>>>>> [snip]
>>>>>>> 2) you grouped the arguments to horizontal and vertical line like
>>>> this:
>>>>>>> (surface, (x1, x2), y, color) and (surface, x, (y1, y2), color)
>>>>>>> respectively
>>>>>>> I find this grouping not very intuitive. normally we group a pair of x
>>>>>>> and y
>>>>>>> coordinates which makes sense because they represent one point but I
>>>>>>> can't see
>>>>>>> such an interpretation here. one could argue to group them (surface,
>>>> (x1,
>>>>>>> y),
>>>>>>> x2, color) but that looks strange as well so I would suggest to not
>>>> group
>>>>>>> them
>>>>>>> at all
>>>>>>>
>>>>>>>
>>>>>> [snip]
>>>>>>> Forrest Voight wrote:
>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> I'm posting the patch at http://im.forre.st/pygame-sdl_gfx.diff , so
>>>>>>>> that won't happen again.
>>>>>>>>
>>>>>>>> It's pretty much a full binding of the shape drawing functions, but
>>>>>>>> there's some other stuff in SDL_gfx.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lenard Lindstrom
>>>>>> <len-l@xxxxxxxxx>
>>>>>>
>>>>>
>>>
>
>