If there's an error, points past the bad point aren't deref'd.
On Thu, Oct 30, 2008 at 7:24 AM, <[EMAIL PROTECTED]> 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" <[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]> >>>> >>> >>> > >
