Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?

[Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx>]

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