Re: [SPAM: 5.000] Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
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.
Re: [SPAM: 5.000] Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
On Sun, 25 Sep 2011 14:18:25 +1300 Greg Ewing greg.ew...@canterbury.ac.nz 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 you pass into drawing calls. But isn't this what I just say? Or did I misunderstand you? Or did you misunderstand me? :o On Sun, 25 Sep 2011 09:55:20 +0200 René Dudfield ren...@gmail.com wrote: Could you create a transform rect like function that returns the transformed state? t(20, 20, 20, 20) (1,1,1,1) That's exactly what I have at the moment (mine is called ``sc()``, but that's irrelevant... :)). I still think that's a missing battery thing though. I haven't browsed much into code of games on pygame.org, but I wouldn't be astonished if a large portion (probably even the majority) of the code would internally use a non-scaled model, to be transformed at representation time... Anyhow: not a big issue, it's just that is not an uncommon feature in other libraries and I feel that inserting it in pygame would make pygame better, but I *can* live without. :) /mac
Re: [SPAM: 5.000] Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
On Sun, Sep 25, 2011 at 11:57 AM, Mac Ryan quasipe...@gmail.com wrote: On Sun, 25 Sep 2011 14:18:25 +1300 Greg Ewing greg.ew...@canterbury.ac.nz 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 you pass into drawing calls. But isn't this what I just say? Or did I misunderstand you? Or did you misunderstand me? :o On Sun, 25 Sep 2011 09:55:20 +0200 René Dudfield ren...@gmail.com wrote: Could you create a transform rect like function that returns the transformed state? t(20, 20, 20, 20) (1,1,1,1) That's exactly what I have at the moment (mine is called ``sc()``, but that's irrelevant... :)). I still think that's a missing battery thing though. I haven't browsed much into code of games on pygame.org, but I wouldn't be astonished if a large portion (probably even the majority) of the code would internally use a non-scaled model, to be transformed at representation time... Anyhow: not a big issue, it's just that is not an uncommon feature in other libraries and I feel that inserting it in pygame would make pygame better, but I *can* live without. :) /mac It's a feature I've used on apps myself, but differently for a number of them. There's a million different transforms that you could do. From scaling, to shearing to rotation, to random quaternions or matrices. I guess you could add an optional transform matrix for every coordinate, or rect and that would work for most cases. I still think a transforming Rect subclass would work best, like your 'sc' function. Otherwise you'd need global state, which is always something pygame tries to avoid. An automatically generated wrapper which transforms any rect, or coord like args could be possible to make... # untested wrapper maker. def transform_rect_like(r): if type(s) in []: #TODO... do rect like detection and return a transformed thing. pass def transform(*args): return tuple([transform_rect_like(a) for a in args]) def transform_kw(*kwargs): return dict([(k, transform_rect_like(v)) for k,v in kwargs.items()]) def make_wrapper(mod, into_obj): for k, f in mod.__dict__.items(): def wrapped_f(*args, **kwargs): return f(*transform(args), **transformkw(kwargs)) setattr(into_mod, k, wrapped_f) make_wrapper(pygame.draw, mydraw) 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. cheers,
Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
On Sun, 25 Sep 2011 12:36:50 +0200 René Dudfield ren...@gmail.com 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. Best, /mac PS: If any other PyGamer who is more fluent in C than I is interested to work on this, I won't in any way feel dispossessed! ;)
Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
On Sun, Sep 25, 2011 at 1:31 PM, Mac Ryan quasipe...@gmail.com wrote: On Sun, 25 Sep 2011 12:36:50 +0200 René Dudfield ren...@gmail.com 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. Best, /mac PS: If any other PyGamer who is more fluent in C than I is interested to work on this, I won't in any way feel dispossessed! ;) Cool, if you like that might be interesting. Just make sure you show your work as you go, so we can see if there's any problems before you do heaps of work. What do you think about generating a wrapper that does it in python similar to the code I posted? cya.
Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
On Sun, Sep 25, 2011 at 7:31 AM, Mac Ryan quasipe...@gmail.com wrote: On Sun, 25 Sep 2011 12:36:50 +0200 René Dudfield ren...@gmail.com 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
Re: [SPAM: 5.000] Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?
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 main surface, you create a subsurface and pass it to your drawing routines. -- Greg
