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

Re: [pygame] SDL_gfx integration



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