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

Re: [pygame] SDL_gfx integration



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>
>>>>
>>>
>>>
>
>