[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Native PyGame method for automatically scaling inputs to a surface resolution?



On Sun, 25 Sep 2011 13:37:41 +0200
Renà Dudfield <renesd@xxxxxxxxx> 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 <cosmologicon@xxxxxxxxx> 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.ewing@xxxxxxxxxxxxxxxx> 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