René Dudfield wrote:
I still think a transforming Rect subclass would work best, like your
'sc' function. Otherwise you'd need global state,
The state wouldn't be global, it would be an attribute of the
surface, like the clipping rect is now. If you don't want to
pollute the state of your mai
On Sun, Sep 25, 2011 at 7:31 AM, Mac Ryan wrote:
> On Sun, 25 Sep 2011 12:36:50 +0200
> René Dudfield 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
On Sun, Sep 25, 2011 at 1:31 PM, Mac Ryan wrote:
> On Sun, 25 Sep 2011 12:36:50 +0200
> René Dudfield 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
On Sun, 25 Sep 2011 12:36:50 +0200
René Dudfield 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 y
On Sun, Sep 25, 2011 at 11:57 AM, Mac Ryan wrote:
> On Sun, 25 Sep 2011 14:18:25 +1300
> Greg Ewing wrote:
>
> > Mac Ryan wrote:
> >
> > > The behaviour that I envisage would be an
> > > optional keyword argument ``scale=1.0`` for rectangles (and
> > > surfaces).
> >
> > I would say the transfor
On Sun, 25 Sep 2011 14:18:25 +1300
Greg Ewing wrote:
> Mac Ryan wrote:
>
> > The behaviour that I envisage would be an
> > optional keyword argument ``scale=1.0`` for rectangles (and
> > surfaces).
>
> I would say the transformation should be an attribute of the
> surface, not something that
Could you create a transform rect like function that returns the transformed
state?
>>> t(20, 20, 20, 20)
(1,1,1,1)
>>> t(20, 20)
(1,1)
pygame.draw.line(s, t(20,20))
I don't know about adding that into every pygame function... that sounds
like too much work.
