On Mon, 03 Oct 2011 17:52:13 +1300
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Could be another parameter for the
surface (coord_system=PIXEL_CENTRE | PIXEL_BOUNDARIES)!! :P
I don't think that would be strictly necessary, because you
would be able to get the same effect by adjusting
Mac Ryan wrote:
Ah, the ambiguities of written langauge! ;) The :P was meant to
indicate it was a joke! :)
Actually that's the danger of using non-standard emoticons. :-)
I think centres is a more appropriate way to describe
position of objects in a modelled space (nobody says the car is
Christopher Night wrote:
Not that it's the most important thing in the world, but I think that
OpenGL agrees with me. Here's a program that creates a scaled surface
extending from (0,0) to (1000, 1000), with a canvas size of 100x100
pixels (so the scale factor is 0.1). It then draws the
On Sun, 02 Oct 2011 14:12:21 +1300
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
If you're going to say that lines are 1-dimensional and thus
infinitely smaller than pixels, and thus we're obliged to draw a
thin rectangle whenever we want a line, then (a) I probably would
not use the tool
On Sun, 02 Oct 2011 13:53:02 +1300
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Now, suppose our arithmetic is a little inaccurate, and we
actually get x = 0.499. The boundaries then come out as -0.001
and 0.999. If we round these, we get 0.0 and 1.0 as before.
But if we floor, we get -1.0
Mac Ryan wrote:
Those inaccuracies would essentially be
the fruit of scaling down a very large physical model to screen
resolution, so I truly wouldn't care if I would expected my
sprite to be 1px to the left or what it appears, as far as the
model performs accurately.
Possibly you wouldn't
Christopher Night wrote:
If I have a 100x100 pixel window,
and I want to put a dot at a position (x,x), it seems to me like the dot
should appear in the window if 0 = x 100. You're saying it should
appear in the window if -0.5 = x 99.5.
You need to be more precise about what you mean by a
Christopher Night wrote:
If you're going to say that lines are 1-dimensional and thus infinitely
smaller than pixels, and thus we're obliged to draw a thin rectangle
whenever we want a line, then (a) I probably would not use the tool if
it doesn't even support drawing lines,
There's no
On Thu, 29 Sep 2011 18:18:48 -0400
Christopher Night cosmologi...@gmail.com wrote:
If I have a 100x100 pixel window, and I want to put a dot at a
position (x,x), it seems to me like the dot should appear in the
window if 0 = x 100. You're saying it should appear in the window
if -0.5 = x
On Fri, Sep 30, 2011 at 5:43 AM, Mac Ryan quasipe...@gmail.com wrote:
On Thu, 29 Sep 2011 18:18:48 -0400
Christopher Night cosmologi...@gmail.com wrote:
If I have a 100x100 pixel window, and I want to put a dot at a
position (x,x), it seems to me like the dot should appear in the
window
On Fri, 30 Sep 2011 09:19:12 -0400
Christopher Night cosmologi...@gmail.com wrote:
Well pixels are just the simplest example. The ambiguity exists for
all drawing functions, not just set_at. For instance, should a
horizontal line extending from (10, 99.6) to (90, 99.6) appear on the
100x100
On Fri, Sep 30, 2011 at 10:38 AM, Mac Ryan quasipe...@gmail.com wrote:
If you are going to use scaled surface you *must* specify the dimension
of what you are drawing.
There are plenty of good reasons you might need a line that's visible
regardless of the dimensions. Here's a screenshot from
Mac Ryan wrote:
I suppose there are various ways of using pygame, but I would still
hold that having the scaling function should be one way only.
As far as drawing is concerned, I tend to agree. The only
difficulty is that some drawing operations in pygame are
defined to return a rect
On Wed, 28 Sep 2011 10:28:12 +1300
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
...because the *INPUT* destination is mapped on s1, and the blit
method should return its *OUTPUT* in unmapped measures [pixels].
Actually that's something to be debated -- *should* it
return post-scaling
On Wed, Sep 28, 2011 at 6:26 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Lenard Lindstrom wrote:
Would you be interested in adding a feature request for a float based rect
class in the issue tracker?
What *would* be useful right now is if the drawing functions would
accept tuples of
Christopher Night wrote:
I've been thinking about this, and even though in the past I've rounded
to int when passing coordinates to drawing functions, I actually think
the correct behavior is to truncate. This makes sense if you consider
the pixel at (0,0) to actually occupy a 1x1 rectangle,
On Thu, Sep 29, 2011 at 5:50 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Christopher Night wrote:
I actually think the correct behavior is to truncate. This makes sense if
you consider the pixel at (0,0) to actually occupy a 1x1 rectangle,
extending from (0,0) to (1,1). So the point
Hi Greg,
Would you be interested in adding a feature request for a float based rect class in the issue tracker? Besides the topic of this thread, what are some other use cases?
Lenard Lindstrom
On Sep 27, 2011, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Mac Ryan wrote: ...because the
Hi Toni,
The new float Rect would not subclass pygame.Rect, as it would have float rather that integer fields. Also, a scaled Surface would automatically return the float Rect.
Having Rect subclass methods return subclass instances is still an issue though. Currently new Rect creation at the C
Lenard Lindstrom wrote:
Would you be interested in adding a feature request for a float based
rect class in the issue tracker?
I think it would make sense more as an adjunct to a coordinate
transformation feature. Once you have surfaces doing transformations,
you're going to want to pass
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
On Tue, Sep 27, 2011 at 2:13 AM, Mac Ryan quasipe...@gmail.com wrote:
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
On Tue, 27 Sep 2011 10:42:10 -0400
Christopher Night cosmologi...@gmail.com wrote:
That's how I understood it... I'm not sure what I said that made it
sound like I was thinking of a two-way transformation Let me try
rephrasing my question using your notation. Please tell me what the
On Tue, Sep 27, 2011 at 11:21 AM, Mac Ryan quasipe...@gmail.com wrote:
One thing that might have further confused the discussion is that
somewhere in an earlier mail I mentioned rects. But all I meant was
really just the rects returned by this kind of operations. I was not
thinking to a new
I wrote a quick demo, using numpy for vectors.
velocity = numpy.array([10., 30.])
http://code.google.com/p/ninmonkey/source/browse/boilerplate/pygame/4.%20with%20numpy%20for%20array/boilerplate%20-%20pygame_with_numpy-2011_jake.py
Euclid is python only, which means you don't need to
On Tue, 27 Sep 2011 11:28:34 -0400
Christopher Night cosmologi...@gmail.com wrote:
How can I use your system to draw a rectangle of a solid color onto a
surface? With the regular pygame system, I would use surf.fill and
pass it a Rect. If your system doesn't recognize rectangles of any
sort,
On Tue, 27 Sep 2011 11:28:34 -0400
Christopher Night cosmologi...@gmail.com wrote:
How can I use your system to draw a rectangle of a solid color onto a
surface? With the regular pygame system, I would use surf.fill and
pass it a Rect. If your system doesn't recognize rectangles of any
sort,
On Tue, Sep 27, 2011 at 3:39 PM, Mac Ryan quasipe...@gmail.com wrote:
On Tue, 27 Sep 2011 11:28:34 -0400
Christopher Night cosmologi...@gmail.com wrote:
How can I use your system to draw a rectangle of a solid color onto a
surface? With the regular pygame system, I would use surf.fill and
On Tue, 27 Sep 2011 15:53:03 -0400
Christopher Night cosmologi...@gmail.com wrote:
Either way, that's fine, and not very suprising. That's exactly what
I had in mind. So I really don't see why you weren't able to answer
my original question. Let me try asking it one more time.
Sorry. The good
Mac Ryan wrote:
...because the *INPUT* destination is mapped on s1, and the blit
method should return its *OUTPUT* in unmapped measures [pixels].
Actually that's something to be debated -- *should* it
return post-scaling or pre-scaling coordinates? A case
could be made for the latter, since
On Sep 28, 2011, at 12:28 AM, Greg Ewing wrote:
However, this would mean that the return value couldn't
be a standard Rect in this case, as it would have to
I found it nice how anything that has rect attribute, is a Rect :)
contain floats. This suggests adding a new float-based
rect class,
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.
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,
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).
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.
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
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
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
Thank you for all your answers. I condensed my reaction in a single
mail:
Julian Marchant onp...@yahoo.com wrote:
What is the purpose to having calculations done with a size that's 10
times larger? If it's just precision, the solution could be simply to
use floats for the calculations and
Are you using numpy?
--
Jake
On Sat, 24 Sep 2011 14:39:31 -0500
Jake b ninmonk...@gmail.com wrote:
Are you using numpy?
No, since I don't have to do very complex or loads of operations I went
with euclid... but I'd be interested in knowing if you have suggestions
involving numpy, nevertheless.
/mac
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. Also
it should allow for both scaling and
What is the purpose to having calculations done with a size that's 10 times
larger? If it's just precision, the solution could be simply to use floats for
the calculations and convert to ints as necessary.
Or, you could write some simple functions or methods that divide the x and y by
10 and
Yeah short answer no. However, I think the answers you've gotten from
StackOverflow have not been terribly helpful. They seem to suggest don't do
scaling in pygame. This is silly, I do scaling in pygame all the time.
There's no reason you'd need to work in screen coordinates.
I use wrappers. Let
Christopher Night wrote:
I use wrappers. Let me point out there's a total of 9 functions in
pygame.draw. You seem to be going to a lot of effort to avoid writing 9
one-line functions.
Don't forget that function calls are expensive in Python, as
is doing piecemeal arithmetic.
Most other
On Fri, Sep 23, 2011 at 7:04 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Christopher Night wrote:
I use wrappers. Let me point out there's a total of 9 functions in
pygame.draw. You seem to be going to a lot of effort to avoid writing 9
one-line functions.
Don't forget that function
46 matches
Mail list logo
