Re: [pygame] line boundingbox

["vimakefile" <vimakefile@yahoo.com>]

I'll wait for 1.1 as I'm not building anything at the moment.

It's seems the easiest model to me to have all operations in-place and just
stick a ".copy()" on the end of the expression if you want the current
behavior -- but then of course current apps may break.

I guess the python model would be to use a method like:
    rect1.union( rect2)
for in-place operations (method is "acting on" rect1) and calls like
    pygame.Rect.Union( rect1, rect2)
for copy-type operations. The capital also makes it explicit that a new
instance is being created, like a class factory.

But anyway, the new API prefix sounds fine to me, as it probably makes sense
at this point and it really is a philosophical thing...

Thanks,
mike

----- Original Message -----
From: "Pete Shinners" <pete@visionart.com>
To: <pygame-users@seul.org>
Sent: Tuesday, May 29, 2001 1:14 PM
Subject: Re: [pygame] line boundingbox


> > I'm using Draw.Line() and trying to manage my dirty rects
> > properly. Line() in sopposed to return the "bouding rectangle
> > of the effected area." However, it's not doing what I expect:
> >
> > An example line (x1, y1, x2, y2) is:
> >
> >     [316.9968184989844, 238.00478049529437] [323.00477415393209,
> > 242.99521823643315]
> >
> > The return value from line is:
> >
> >     <rect(0, 0, 324, 243)>
>
> i've already fixed the line bounding box problems. they were
> definitely 'incorrect' for the 1.0 release. you have two
> options. grab the latest CVS version of pygame, or wait for
> the pygame-1.1 release which isn't far away.
>
> if you'd like something that works with 1.0 and you "know"
> that you aren't using clipping rectangles on your destination
> surface, you can cheat it with something like this...
>
> pygame.draw.line(screen, color, pt1, pt2)
> boundingbox = Rect(pt1, (1,1).union(pt2, (1,1))
>
> i've just gone back and retested that the current pygame
> line drawing does work. i've attached a sample program
> you can test with, here is the output...
>
> D:\src\test>python testline.py
> POINT 0 : [316.9968184989844, 238.00478049529437]
> POINT 1 : [323.00477415393209, 242.99521823643315]
> BOUNDBOX: <rect(316, 238, 8, 5)>
>
> exactly the numbers i would expect
>
>
>
> > Also, it would be nice if Rect operations (such as union)
> > were in-place (destructive) operations rather than creating
> > new objs -- it's easy enough to copy them, but in this case
> > (keeping a running Union) it would be more efficient.
>
> well, this is a tough spot. there are times you definitely
> want both "inplace" and "nondestructive" operation on these
> rects. i chose to go with the way they are, because it ends
> up being easier to do both. (easier than it is to get both
> types of operation when only having the inplace version,
> that is)
>
> the functions are going to remain the way they are, but
> one option that's been tickling my head is to add a second
> set of functions that do the same things but put the results
> inplace. either some sort of prefix/suffix, or a change to
> the "verb" tense...
>
> rect.ip_union(), rect.union_ip(), rect.self_union()
> rect.unioning(), rect.unioned()
>
> the Rect is a very handy utility class, and i'm not opposed
> to making it a bit more flexible. i don't think these additional
> functions would make it too "overwhelming" either?
> any opinions out there?
>
>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org