On Tue, 27 Sep 2011 10:42:10 -0400 Christopher Night <cosmologi...@gmail.com> wrote:
> That's how I understood it... I'm not sure what I said that made it > sound like I was thinking of a two-way transformation.... Let me try > rephrasing my question using your notation. Please tell me what the > following would output (where I have question marks), and tell me if > you don't understand what I mean by the pseudocode: > > >>> init_surface(scale_factor = 0.1) > >>> r1 = myrect(0, 0, 108, 10) > >>> r1.left = 4 > >>> fill_rect(r1) > >>> get_size_bounding_rect() > ??? x ??? Hi Chris, sorry, reading your reply I understood that my notation was probably not very clear. I'm still not sure I got you, but here's a more articulated example of what I mean, using standard pygame syntax (bar the ``scale`` parameter): >>> s1 = pygame.surface.Surface((100,100), scale=0.1) This will initialise a surface of 10x10 px, "mapping" a 100x100 square. >>> s1.get_bounding_rect() <rect(0, 0, 10, 10)> ...because the image is 10x10 pixels. >>> s2 = pygame.surface.Surface((100,100), scale=0.05) >>> s2.get_bounding_rect() <rect(0, 0, 5, 5)> >>> s1.blit(s2, (20,20)) <rect(2, 2, 5, 5)> ...because the *INPUT* destination is "mapped" on s1, and the blit method should return its *OUTPUT* in unmapped measures [pixels]. One thing that might have further confused the discussion is that somewhere in an earlier mail I mentioned "rects". But all I meant was really just the rects returned by this kind of operations. I was not thinking to a new class of rects with scaling included. I'm far from asserting that what above is the best way ever to implement scaling in PyGame, but this is how I imagined it working. I'm very open to hear alternative suggestions and feedback, of course! Also: does this address your doubts? /mac