On Sun, Sep 25, 2011 at 7:31 AM, Mac Ryan <[email protected]> wrote:
> On Sun, 25 Sep 2011 12:36:50 +0200 > René Dudfield <[email protected]> wrote: > > > Maybe it would be possible to implement easily in C, without too much > > code, but maybe not. I'm not interested in it myself, since I think > > it's not too hard to layer on top - so I won't spend any effort > > implementing it. However, if you want to submit a patch that doesn't > > make the code super ugly, and doesn't cost too much performance we > > could add it. > > I can have a go at it - without guarantees as I only occasionally code > in C - but that won't be immediately anyhow, most likely not before > 15/10. If you have any further suggestion before I try to make my way > through the code, I'll be happy to listen. > > I have several questions that I would want addressed before I used your tool extensively. Should I post them to this thread or what? There's a number having to do with tricky edge cases of the transformation. When I write my own wrappers I know what to expect, so I would need it well documented for yours. For example.... Suppose the current transformation is (x, y) -> (0.1x, 0.1y). What pygame Rect will the following correspond to (after all the coordinates are coerced to ints)? rect1 = rect2 = myRect(0, 0, 108, 10) rect1.left = 4 rect2.right = 112 Should the pygame rects produced by rect1 and rect2 be the same? Either answer is surprising, I think. (That question assumes you're rounding down to coerce to ints. If instead you're rounding to the nearest, consider this example) rect1 = rect2 = myRect(0, 0, 104, 10) rect1.left = 4 rect2.right = 108 Anyway, that's just one question, I'd just want to make sure you'd thought it through. -Christopher
