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

[Mac Ryan <quasipedia@xxxxxxxxx>]

On Wed, 28 Sep 2011 10:28:12 +1300
Greg Ewing <greg.ewing@xxxxxxxxxxxxxxxx> wrote:

> > ...because the *INPUT* destination is "mapped" on s1, and the blit
> > method should return its *OUTPUT* in unmapped measures [pixels].  
> 
> Actually that's something to be debated -- *should* it
> return post-scaling or pre-scaling coordinates? A case
> could be made for the latter, since the code using the
> scaled surface is doing all its other calculations in
> those coordinates, and having to manually transform
> back would be a nuisance.

I suppose there are various ways of using pygame, but I would still
hold that having the scaling function should be "one way only". Some
random thoughts about it:

1. Domain separation: pygame is about managing graphics on the screen,
   not about managing a mathematical model. A scale factor for input
   coordinates is a transparent, non-obstructive addition. Having
   returned rectangles that do not match what is on screen is not, it
   requires you to alter the way you handle graphic.
2. Code incompatibility: code that has been written assuming images are
   not scaled may not run correctly if scaling is introduced at a later
   stage: with your proposal the very **meaning** of the returned
   rectangle would be different that what is now.
3. Scaling mess: a concrete example... In the application I am
   developing now, I scale the modelled space to match screen
   resolution, but since the objects moving in the space might have
   sub-pixel dimensions if scaled to the same resolution, I am
   often obliged to scale the sprites representing them to a different
   resolution (depending on their size) in order to be sure to have
   something distinguishable on screen. It would be all but a nuisance
   to keep track of all the different resolution when doing math on
   sprites rects.

The idea of float rectangles per se doesn't seem to have any of these
problems, yet the underlying thought seems (correct me if I am wrong!)
that you would use rectangles for keeping track of your models, rather
than of their on-screen representation [which couldn't be anything else
than integer coordinates]... Again: there are many ways to use pygame
and I can't (nor wish to) say this is wrong... It just seems to me that
working in non-integer coordinates would subtly change the semantics of
pygame, and wanted to point that out.

/mac