On Sun, Sep 25, 2011 at 7:31 AM, Mac Ryan
<quasipedia@xxxxxxxxx> wrote:
On Sun, 25 Sep 2011 12:36:50 +0200
> 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
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
Anyway, that's just one question, I'd just want to make sure you'd thought it through.