Re: [pygame] draw.line bounding box bug when width>1
Fixed in svn rev. 2808 (after a considerable delay). Thanks Aaron Brady
and Rolf Sievers.
Lenard Lindstrom
Rolf Sievers wrote:
I finally got an Ubuntu - compiling is easy now :-)
Last patch didn't work, there where syntax/logic problems with { and }.
I have got a new patch for you that compiled and works as expected
(try my demo of the bug: http://python.pastebin.com/f2292e1d9)
I accidentally pastebined the diff, so I might just post a link:
http://python.pastebin.com/f2228be1c
Because I don't know how to do that, there is no unit test.
my diff is also attached to this email
Rolf Sievers
Lenard Lindstrom schrieb:
Thanks Rolf,
There is definitely a problem with pygame.draw.line and I will give
your patch a try. What is missing is a good unit test to define the
expected behavior. I will write one up.
Lenard Lindstrom
Rolf Sievers wrote:
I just realized that won't work - I didn't exchange the line ends
properly
try this patch
Rolf Sievers schrieb:
meh...
I guess I can make a patch even if I can't compile. Some work for
my little Tortoise.
Could someone with a compiler tell me if it works?
I used a temp variable here and fixed a line that was broken in my
last mail.
Re: [pygame] draw.line bounding box bug when width>1
I finally got an Ubuntu - compiling is easy now :-)
Last patch didn't work, there where syntax/logic problems with { and }.
I have got a new patch for you that compiled and works as expected (try
my demo of the bug: http://python.pastebin.com/f2292e1d9)
I accidentally pastebined the diff, so I might just post a link:
http://python.pastebin.com/f2228be1c
Because I don't know how to do that, there is no unit test.
my diff is also attached to this email
Rolf Sievers
Lenard Lindstrom schrieb:
Thanks Rolf,
There is definitely a problem with pygame.draw.line and I will give
your patch a try. What is missing is a good unit test to define the
expected behavior. I will write one up.
Lenard Lindstrom
Rolf Sievers wrote:
I just realized that won't work - I didn't exchange the line ends
properly
try this patch
Rolf Sievers schrieb:
meh...
I guess I can make a patch even if I can't compile. Some work for my
little Tortoise.
Could someone with a compiler tell me if it works?
I used a temp variable here and fixed a line that was broken in my
last mail.
Index: draw.c
===
--- draw.c (Revision 2687)
+++ draw.c (Arbeitskopie)
-678,14 +678,29 @@
{
int loop;
int xinc=0, yinc=0;
+ int temp;
int newpts[4];
int range[4];
int anydrawn = 0;
if(abs(pts[0]-pts[2]) > abs(pts[1]-pts[3]))
+ {
yinc = 1;
+ if(pts[1]>pts[3])
+ {
+ temp = pts[0]; pts[0] = pts[2]; pts[2] = temp;
+ temp = pts[1]; pts[1] = pts[3]; pts[3] = temp;
+ }
+ }
else
+ {
xinc = 1;
+ if(pts[0]>pts[2])
+ {
+ temp = pts[0]; pts[0] = pts[2]; pts[2] = temp;
+ temp = pts[1]; pts[1] = pts[3]; pts[3] = temp;
+ }
+ }
memcpy(newpts, pts, sizeof(int)*4);
if(clip_and_draw_line(surf, rect, color, newpts))
Re: [pygame] draw.line bounding box bug when width>1
Thanks Rolf, There is definitely a problem with pygame.draw.line and I will give your patch a try. What is missing is a good unit test to define the expected behavior. I will write one up. Lenard Lindstrom Rolf Sievers wrote: I just realized that won't work - I didn't exchange the line ends properly try this patch Rolf Sievers schrieb: meh... I guess I can make a patch even if I can't compile. Some work for my little Tortoise. Could someone with a compiler tell me if it works? I used a temp variable here and fixed a line that was broken in my last mail.
Re: [pygame] draw.line bounding box bug when width>1
I just realized that won't work - I didn't exchange the line ends properly
try this patch
Rolf Sievers schrieb:
meh...
I guess I can make a patch even if I can't compile. Some work for my
little Tortoise.
Could someone with a compiler tell me if it works?
I used a temp variable here and fixed a line that was broken in my
last mail.
Index: draw.c
===
--- draw.c (revision 2664)
+++ draw.c (working copy)
@@ -678,13 +678,20 @@
{
int loop;
int xinc=0, yinc=0;
+ int temp;
int newpts[4];
int range[4];
int anydrawn = 0;
if(abs(pts[0]-pts[2]) > abs(pts[1]-pts[3]))
+ if(pts[1]>pts[3])
+ temp = pts[0]; pts[0] = pts[2]; pts[2] = temp;
+ temp = pts[1]; pts[1] = pts[3]; pts[3] = temp;
yinc = 1;
else
+ if(pts[0]>pts[2])
+ temp = pts[0]; pts[0] = pts[2]; pts[2] = temp;
+ temp = pts[1]; pts[1] = pts[3]; pts[3] = temp;
xinc = 1;
memcpy(newpts, pts, sizeof(int)*4);
Re: [pygame] draw.line bounding box bug when width>1
meh...
I guess I can make a patch even if I can't compile. Some work for my
little Tortoise.
Could someone with a compiler tell me if it works?
I used a temp variable here and fixed a line that was broken in my last
mail.
Index: draw.c
===
--- draw.c (revision 2664)
+++ draw.c (working copy)
@@ -678,13 +678,18 @@
{
int loop;
int xinc=0, yinc=0;
+ int temp;
int newpts[4];
int range[4];
int anydrawn = 0;
if(abs(pts[0]-pts[2]) > abs(pts[1]-pts[3]))
+ if(pts[1]>pts[3])
+ temp = pts[1]; pts[1] = pts[3]; pts[3] = temp;
yinc = 1;
else
+ if(pts[0]>pts[2])
+ temp = pts[0]; pts[0] = pts[2]; pts[2] = temp;
xinc = 1;
memcpy(newpts, pts, sizeof(int)*4);
Re: [pygame] draw.line bounding box bug when width>1
Your example code didn't work for me, I made a little interactive example of the problem: http://python.pastebin.com/m66dfd8c1 it allows you to draw a line with your mouse and see line and rect (updated in realtime) > This bug was already addressed in a DOC post in 2005, > http://www.pygame.org/docs/ref/draw.html#pygame.draw.line > I'm not really sure why no one included the patch. I attempted 'inflate', but didn't account for the width. I just tried a range of constants. So does it work with that code or are there still errors? Perhaps that's why it hasn't been patched (because the example code doesn't work in all situations). If you look at the source for the method and you see where the calculation error is occurring, you could submit a diff patch or maybe upload a revision to SVN or something. Then you can say you contributed to an open-source project on your resume :) You can uncomment a line in my example above to see that the workaround works just fine. (There is no patch, only a python workaround) The rect delivered by the workaround is sometimes bigger than necessary. (also easily visible in my example) pygame.draw.line's C code seems to rely on the clip_and_draw_line_width(..) function which does not work as expected. Search trunk/src/draw.c for the definition. (I can't see linenumbers on seul.org) While I know some python and learn Delphi at school I'm C/C++ illiterate but I might be able to fix the problem, this basically is supposed to be a patch not in diff, but English. I guess that those lines are responsible: range[0] = MIN(newpts[0], range[0]); range[1] = MIN(newpts[1], range[1]); range[2] = MAX(newpts[2], range[2]); range[3] = MAX(newpts[3], range[3]); I guess the code somewhere assumes the first point is topleft of the second, draw a broken line in the opposite direction (example prog) and you can see what I mean. If I don't want to touch those lines (because I wouldn't know how) the function (clip_and_draw_line_width) should check if there is a problem and if so switch the points. These are the lines I would edit: if(abs(pts[0]-pts[2]) > abs(pts[1]-pts[3])) yinc = 1; else xinc = 1; Because those lines already "know" in which direction the line might leave the rect. if(abs(pts[0]-pts[2]) > abs(pts[1]-pts[3])) if(pts[1]>pts[3]) /*if it doesn't work, try < */ yinc = pts[1]; pts[1] = pts[3]; pts[3] = yinc /* I abuse yinc here, because I don't want to declare another var*/ yinc = 1; else if(pts[0]>pts[2]) /*if it doesn't work, try < */ xinc = pts[1]; pts[1] = pts[3]; pts[3] = xinc xinc = 1; I hope that helps, and works - If you don't want to abuse yinc and xinc, declare a war. Thank you for reading till this point, I'm sorry that my English isn't that good but I hope you where able to understand if not, feel free to ask/point it out.
Re: [pygame] draw.line bounding box bug when width>1
On Tue, Oct 13, 2009 at 4:09 AM, Aaron Brady wrote: > On Sun, Oct 11, 2009 at 1:07 PM, Luke Paireepinart > wrote: > > > > > > On Sat, Oct 10, 2009 at 10:57 PM, Aaron Brady > wrote: > >> > >> Hello, > >> New to the list. > >> I have a bug! Nice 'n' easy repro steps below. > > > > Just FYI, > > http://catb.org/~esr/faqs/smart-questions.html#id382249 > > Ah I see. Too informal and hasty. For the record, I like these parts > of this link: > > "...claim you have found a bug, you'll be impugning their competence, > which may offend..." > > and > > "...it is best to write as though you assume you are doing something > wrong, even if you are privately pretty sure..." > > Is it appropriate to share what I'm pleased with? > Adrian, Yes, that article is quite good and you'll see it linked on technical mailing lists a lot. I recommend reading the whole article if you have time. It's by Eric Raymond, which many people have differing opinions on, but most people seem to agree that that particular article sums up technical fora's etiquette quite well. As far as what's appropriate, I don't know. I didn't find anything offensive about your post, but then again I'm not a core Pygame developer. They're pretty cool guys though, and your post was probably not offensive to anyone, which is why I said "FYI" not "RTFM", so you'd know that in some situations a bug report can be misconstrued :) In general it's better to err on the side of politeness when you're first approaching a new group and only moving to more familiar terminology once you've been on the list for a while and you've got a good feeling for how everyone talks to each other. I don't know how long you've been on this particular list though, just some general advice. > > > This bug was already addressed in a DOC post in 2005, > > http://www.pygame.org/docs/ref/draw.html#pygame.draw.line > > I'm not really sure why no one included the patch. > > I attempted 'inflate', but didn't account for the width. I just tried > a range of constants. > So does it work with that code or are there still errors? Perhaps that's why it hasn't been patched (because the example code doesn't work in all situations). If you look at the source for the method and you see where the calculation error is occurring, you could submit a diff patch or maybe upload a revision to SVN or something. Then you can say you contributed to an open-source project on your resume :)
Re: [pygame] draw.line bounding box bug when width>1
On Sun, Oct 11, 2009 at 1:07 PM, Luke Paireepinart wrote: > > > On Sat, Oct 10, 2009 at 10:57 PM, Aaron Brady wrote: >> >> Hello, >> New to the list. >> I have a bug! Nice 'n' easy repro steps below. > > Just FYI, > http://catb.org/~esr/faqs/smart-questions.html#id382249 Ah I see. Too informal and hasty. For the record, I like these parts of this link: "...claim you have found a bug, you'll be impugning their competence, which may offend..." and "...it is best to write as though you assume you are doing something wrong, even if you are privately pretty sure..." Is it appropriate to share what I'm pleased with? > This bug was already addressed in a DOC post in 2005, > http://www.pygame.org/docs/ref/draw.html#pygame.draw.line > I'm not really sure why no one included the patch. I attempted 'inflate', but didn't account for the width. I just tried a range of constants.
Re: [pygame] draw.line bounding box bug when width>1
On Sun, Oct 11, 2009 at 11:07 AM, Luke Paireepinart wrote: > This bug was already addressed in a DOC post in 2005, > http://www.pygame.org/docs/ref/draw.html#pygame.draw.line > I'm not really sure why no one included the patch. > I actually tried this solution, and it only sort-of works.
Re: [pygame] draw.line bounding box bug when width>1
On Sat, Oct 10, 2009 at 10:57 PM, Aaron Brady wrote: > Hello, > New to the list. > I have a bug! Nice 'n' easy repro steps below. > Just FYI, http://catb.org/~esr/faqs/smart-questions.html#id382249 This bug was already addressed in a DOC post in 2005, http://www.pygame.org/docs/ref/draw.html#pygame.draw.line I'm not really sure why no one included the patch.
Re: [pygame] draw.line bounding box bug when width>1
On Sat, Oct 10, 2009 at 1:57 PM, Aaron Brady wrote: > For single occurrence: > import pygame > pygame.init( ) > print pygame.version.ver > s= pygame.Surface( ( 20, 20 ) ) > rec= pygame.draw.line( s, >( 255,0,0 ), >( 10, 16 ), >( 7, 0 ), >2 ) > rec is wrong for many thicknesses. Is this a bug?
