Mac Ryan wrote:
Ah, the ambiguities of written langauge! ;) The ":P" was meant to indicate it was a joke! :)
Actually that's the danger of using non-standard emoticons. :-) > I think "centres" is a more appropriate way to describe
position of objects in a modelled space (nobody says "the car is in the far end left corner of the garage", as intuitively we consider the geometrical centre of objects as their most significative one for positional reference).
The garage is not a point, it's a rectangle, and so is the car. Saying "the car is in the garage" means that the boundaries of the car lie within the boundaries of the garage. It's not sufficient to say that the *centre* of the car is in the garage; the door might be open and the boot[1] sticking out into the driveway. Conversely, it's too restrictive to say that the centre of the car is at the centre of the garage, since (unless your garage is *really* tight for space) there are other locations for the car's centre such that the car is still inside the garage.
OTOH, boundaries are way more consistent with how PyGame operates on standard surfaces.
That's the clincher, I think. In PyGame you're very often dealing with rects in one way or another, and in my experience, rects just work better with pixel-boundary coordinates. For example, if you have a rect with left=10 and right=20, and another with left=20 and right=30, it's obvious that they will touch without overlapping. With pixel-centre coordinates, you have to think about it a bit harder, plus you need some rule such as half-open rect coordinates to make it work. This is similar to the way it helps to think of slice indices in Python as labelling points between items rather than the items themselves. It's the same thing in two dimensions. [1] Or trunk, if it's an American car and/or garage. -- Greg