On Sun, 25 Sep 2011 13:37:41 +0200 René Dudfield <ren...@gmail.com> wrote:
> 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. Will do. As I said, no guarantees though! :) > What do you think about generating a wrapper that does it in python > similar to the code I posted? If I were to do it in python I'm sure I could do it. I have very limited experience in C, but I would guess C would be a more sensible choice though: the scaling procedure would potentially called rather often (every time something is draw on that surface) so it seems sensible to me to try to make as fast performing as possible... or not? :-/ On Sun, 25 Sep 2011 11:41:19 -0400 Christopher Night <cosmologi...@gmail.com> wrote: > 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)? Could you please articulate a bit more? I'm not sure I followed. From your post it seems to me that you are imagining a two-way transformation in which you use model-scaled data to the draw function (draw a 150 metres radius circle) and you also get model-scaled data when you query the object (what is the size of the bounding rect for the circle? --> 300 metres). What I am talking about is just a "one-way" transformation that convert the input of the drawing functions. In pseudocode: >>> init_surface(scale_factor=0.1) >>> draw_circle(radius=150) >>> get_size_bounding_rect() ... 30x30 For me pygame is only a presentation layer, all my "game logic math" is done elsewhere. As for the "graphic math" (sprite collision, etc...) is just fine to do it at screen resolution, so I am happy for pygame to keep on thinking that my circle is 30x30 pixels. But maybe I misunderstood what you meant? On Mon, 26 Sep 2011 09:55:01 +1300 Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > 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. Indeed. I did not yet look at the code, but my preliminary idea is that if scale == 1.0, then a standard surface should be initialised, if it is not, then a surface which scales inputs should. This would spare the effort of multiplying by 1 the parameters for non-scaled surfaces. However, I think I'm thinking "object orientation" here, and if I am correct, pygame is coded in regular C. ??? [Again: will probably need some direction here]. /mac