[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Rects and they handle right and bottom borders



Nelson, Scott wrote:
Ok, theory question about Rects...

I understand how a rect works, but I'm interested in why it works the
way it does to help flesh out my understanding...

Originally, I was playing with code that looked something like this:

r = pygame.display.get_surface().get_rect()

If I would do r.width, I'd get 640.  Makes sense since the display is
640 pixels wide.  But, r.right returns 640.  In my mind, a pixel with an
x index of 640 is off the display since the pixels are numbered 0-639.
My assumption is that r.right would return the index of the last pixel
on the right edge of the rectangle (639).  Apparently a wrong
assumption.  So, then I actually read the docs on Rect a bit closer:

"The area covered by a Rect does not include the right- and bottom-most
edge of pixels. If one Rect's bottom border is another Rect's top border
(i.e., rect1.bottom=rect2.top), the two meet exactly on the screen but
do not overlap, and rect1.colliderect(rect2) returns false."

Ok, that is obviously consistent with my observed results.  So, I now
understand how it works, but could anyone shed some light as to why it
was done this way?  Is it to mirror Python's other behaviors, such as
range(3) or slicing's [0:3]?  Does SDL simply do it this way?  Something
else?

Thanks for indulging me on this hair splitting...

-Scott


This matches Python's 'range' feature, as well - range(100) gives you 0 through 99.

I personally like it this way. I've written a sprite engine in C and DIDN'T handle rects this way, I had it include the rightmost pixel - and there was lots more housekeeping.