On Wed, 28 Sep 2011 10:28:12 +1300 Greg Ewing <[email protected]> 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
