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