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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> > 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 >>> <[EMAIL PROTECTED]> >>> >> >>
